I believe Tcl scripts can help automate your FSBL and BSP changes. Pretty much everything you do in the GUI translates to Tcl commands.
153 karma · joined December 30, 2014
See myth 7 here: http://www.electronicdesign.com/eda/11-myths-about-hardware-...
The reasons are numerous. I already gave a few. I will give another. Once you have to integrate hard IP from other parties, you cannot synthesise it to FPGA. Which means you won't be able to run any FPGA verification with that IP in the design. You can get a behavioural model that works in simulation only. In fact it is usually a requirement for Hard IP to be delivered with a cycle accurate model for simulation.
I'll give another reason. If you are verifying on FPGA you will be running a lot faster than simulation. The Design Under Test requires test stimulus at the speed of the FPGA. That mans you have to generate that stimulus at speed and then check all the outputs of the design against expected behaviour at speed. This means you have to create additional HW to form the testbench around the design. This is a lot of additional work to gain speed of verification. This work is not reusable once the design is synthesised for ASIC.
I can go on and on about this stuff. Maybe there are reasons for a particular product but I am talking about general ASIC SoC work. I got nothing against FPGAs. I am working on FPGAs right now. But real ASIC work uses simulation first and foremost. It is a dominant part of the design flow and FPGA validation just isn't. On a "Ask HN", you would be leading a newbie the wrong way to point to FPGAs. It is not done a lot.
Exactly. When you verify a design via an FPGA you are only essentially testing the RTL level for correctness. Once you synthesise for FPGA rather than the ASIC process, you diverge. In ASIC synthesis I have a lot more ability to meet timing constraints.
So given that FPGA validation only proves the RTL is working, ASIC projects don't focus on FPGA. We know we have to get back annotated gate level simulation test suite passing. This is a major milestone for any SoC project. So planning backwards from that point, we focus on building simulation testbenches that can work on both gate level and RTL.
I am not saying FPGAs are useless but they are not a major part of SoC work for a reason. Gate level simulation is a crucial part of the SoC design flow. All back end work is.
The ability to perform constrained randomised verification is only workable via UVM or something like it. For large designs that is arguably the best verification methodology. Without visibility through the design to observe and record the possible corner cases of transactions, you can't be assured of functional coverage.
While FPGAs can run a lot more transactions, the ability to observe coverage of them is limited.
I have worked on multiple SoCs for Qualcomm, Canon and Freescale. FPGAs don't play a role in any SoC verification that I've worked on.
The skills to do front end work are similar but an ASIC design flow generally doesn't use an FPGA to prototype. They are considered slow to work with and not cost effective.
IP cores in ASICs come in a range of formats. "Soft IP" means the IP is not physically synthesised for you. "Hard IP" means it has been. The implications are massive for all the back end work. Once the IP is Hard, I am restricted in how the IP is tested, clocked, resetted and powered.
For front end work, IP cores can be represented by cycle accurate models. These are just for simulation. During synthesis you use a gate level model.
Maybe engineers need to be introduced to the synthesis tools at the same time as the simulator tools.
Simulating RTL is only an approximation of reality. So emphasizing RTL simulation is bad. You see it over and over though. People teach via RTL simulation.
Synthesis is the main concern. Can the design be synthesised into HW and meet the constraints? Because all the combinatorial logic gets transformed into something quite different in a FPGA.
You stuck to your guns and didn't just lie about Unix experience, so I commend you.
But if you really want the job, next time just lie and set them straight once you've gotten an interview. It is splitting hairs to make a big deal out of actual Unix experience vs Linux experience.
But the language is just a small part of the design process. You have to be learn to design HW. The HW engineering project tailors the tool choices around the requirements of the product. It is assumed that engineers know the fundamentals. They can adapt to any high level synthesis tool.
Vendors training courses for all fancy HLS tools are done in a few days at most. They don't have a semester for any newbies to learn Verilog/VHDL or C/C++ first. It's assumed you know them.
It's tool dependent but I believe you should see a warning that two drivers are assigned to the same net.
This is probably where I am guessing you mistakenly thought you were creating a register in Verilog with the keyword "reg". Synthesis tools don't work like that and haven't for quite a while.
Taken from https://blogs.mentor.com/verificationhorizons/blog/2013/05/0... :
"Initially, Verilog used the keyword reg to declare variables representing sequential hardware registers. Eventually, synthesis tools began to use reg to represent both sequential and combinational hardware as shown above and the Verilog documentation was changed to say that reg is just what is used to declare a variable. SystemVerilog renamed reg to logic to avoid confusion with a register – it is just a data type (specifically reg is a 1-bit, 4-state data type). However people get confused because of all the old material that refers to reg."
A lot of people here on HN seem to be self taught and not keeping up with tool and language developments. If you use tools and techniques from the 90s, don't expect wonderful results.
Designs are getting larger these days with a lot of 3rd party IP that you can't assume use a particular reset method.
Tips #2 and #5 in this article, http://www.eetimes.com/document.asp?doc_id=1278998 , explain how you have to tailor your reset methods to the modules you are integrating.
If you don't, you chew up resources.
A new FPGA designer should learn the first principles so they can understand how to make decisions and where to look for potential issues when bugs occur.
Your example is somewhat pointless. The code is written to create the HW not the other way around. I can't feed it just any crap.
You want parallelism you have to code it.
Zynq would actually be what I use! You start with SW. The ARM core is not that quick. You will use the FPGA to accelerate the tough parts. You may think you will have throughput issues but you have options via the high performance AXI ports. Your FPGA modules access the data in memory via DMAs.
KNOWING what part of the algorithm you need to accelerate actually suits FPGAs, you grab the HLS and start coding.
You have to look at some of the libraries to understand what abstraction level you are working at: https://www.xilinx.com/products/design-tools/vivado/integrat...
Video, matrices, linear algebra, encoders/decoders. Etc. I can string them together in the same way I would string HDL IP.
The advantage is I can run the algorithm in C++ first and test it all, under the assumption that the HLS library has the equivalent HW version for synthesis.
There is still a lot of HW work involved. For instance in your example with A used twice. One module would calculate B_out by reading A prior to changing its value then you would have to start the C_out module. You would need a way to coordinate the two modules to share the same memory at A. But they would be running in parallel, just not started at the same time.
Both Xilinx and Altera have High Level Synthesis (HLS) tools. These use C or C++. If you know how FPGA work is generally done, you can separate the hype from the reality and you can understand how to use it for a real application.
The vendors have lots of libraries for IP. You don't write RTL from scratch. It would take too long to verify. You tie IP together. It can be DSP or generic maths or a video codec thing. The VHDL is done for you.
You write your algorithm in C++ in a particular format using compatible data types and calling HLS libraries. You run it all in C++ first and make sure it does exactly what you want in SW. This is where the algorithm is developed.
THEN you fire up the HLS tool and a couple of hours of synthesizing later (lol) you get to load a bitstream onto a FPGA to verify it.
Of course there can be problems in that translation. It takes good engineering to dive down into the design and find the issues.
My current work does not touch any HLS. I am doing the VHDL stuff. But I know the algorithms all started from SW first. It always does. For the bulk of the work, verification, it is somewhat irrelevant whether it is manually converted to RTL or done via tools.
>- jump to previous commands.
>You just ran a command that printed a few pages, you want to scan from the first line.
>- collapse previous outputs (stderr / stdout / both)
> Let me toggle stdout / stderr after the command has been run.
>- connect a pipe to a previously run command
>... But why can't you re-use the output that is there in the terminals scrollback buffer?
I am working in the FPGA industry. I definitely agree with you.
But possibly I am a little too close to the current industry and way we do things. There's new applications around the corner that need innovative ideas. The innocent fresh perspective could be the seed for something. I am sure if any real decent improvements were started by a SW person, the big companies like Intel would be eating it up.
It funny how people on HN were raving about Altera & Intel recently because word on the FPGA street was that Intel weren't happy with the acquisition. Xilinx has had 14nm FPGAs for a long time while Altera's are nowhere to be seen still. Everyone's expectations of a Xeon with Altera FPGA on the same die are years away I am betting.
Median tenure is falling I believe. And employees in their mid-twenties and thirties have way lower tenure than those in their fifties. I think it's about 3 years as opposed to 10 years. Job-hunting is much more prevalent.
Hence the "TCS" jab from empressplay. A lot of IT contracts for major companies in Australia are outsourced to multinational IT companies. Those multinationals use a lot of 457 workers and get the big contracts via undercutting and paying low wages to poor migrants.
Then various politicians have attacked the 457 scheme over the years. Most recently, one government backbencher from a regional mining area where unemployment is still very high threatened to quit over it.
It's reputation has been shady for quite a while. It is always raised in a bad light by the media due to abuses.
I do feel that this current move has unfairly affected legit skilled researchers like a_bonobo though. How they manage to be lumped in with 457s brought in by outsourcing companies makes zero sense.
Innovation is corporate-speak for actual company processes where they change things up like their business model, or their target customers or their product etc. I believe he is talking about teaching some of those techniques in an education environment.
The attributes he mentions (relationships, curiosity, agility, creativity, empathy) are teachable skills in that context. The sort of lateral thinking exercises that Edward De Bono advocates or other brainstorming methods are used in the more kiddy version in alternative style schools like Montessori or Steiner schools.
In those schools it is an active-learning, constructivist philosophy where kids have to cooperate with each other on projects and seek out the info rather than be fed info. It's not like practical skills aren't taught. Some are very hands-on. They might build a windmill or something. As they do, they learn all about physics and mechanics.
As someone from the FPGA industry, bigger projects just use your CASE 3 on a board to start prototyping. A Zedboard or similar. Cheaper version could be the Zybo. It's like $500 vs $200.
When you get to production stage, you whip up your own board.
What exactly is your complaint about the propriety tools? You are using Altera tools with the DE0 Nano.
If they don't spare a thought for what future problems can come up and make allowances and contingencies for these risks then they can't manage. Who cares if you tell them about problems early if there's no ability/wiggle room to change directions?
If management don't want surprises, try thinking ahead. It's called risk management. Who is to blame when a predictable issue eventuates? Not engineering. If you have no slack in the schedule get ready for shit to hit the fan.
If we scan this thread we could come up with a list of issues/problems with UNIX. Human inclination is to instantly look for each solution as each problem presents itself. Eg. "Text as an interface is unstructured" -> "Use other formats". The end result becomes a lot of feature creep, adding layers over the OS to hide the usability issues of the past. Then, a new user comes along and wonders, "How did it all get so messy?"
The ideation-style approach to innovation is NOT to leap straight to solutions. Avoid analyzing the problems immediately. Don't criticize other people's existing thoughts.
Instead we use our creativity to add to the list of problems. We build it up even more. Add tangential issues that may be not just UNIX related problems. Add future issues. Add past issues. You keep adding until you exhaust all the avenues. You don't want to block your thoughts or anyone else's. If anything, the previous problem someone raises should inspire your next one.
Once you have drained out all the issues and you can't squeeze out any more complaints, then you can take a step back and look at all the problems as a whole. You group them into categories that have common themes. You try to generalize and re-express them in vaguer terms.
After you have your themes, you can think about making a list of solutions. Again you don't want to be critical about the feasibility of a solution. You just want to build a list of different solutions. Each solution should inspire a new different solution. There are mental exercises that you can do to inspire tangential thoughts - word games etc.
When you have a giant list of solutions, then you categorize again. Those categories are the start point to building something innovative.
The alternative is just another iteration of what already exists.
My own thoughts on this are that I seem to need "power-user" abilities way too much. My field is actually Hardware. Something is wrong if I am jumping through a lot of hoops outside of my specialty just to get work done. It's not just UNIX either. My friends and family often call on me to handle their Windows or Mac issues because I am the closest thing to an expert they know. They shouldn't have to.
The tools are trying to help. The end product is the physical device. The various models are all just abstractions of the physical device. The tools are reporting the problems on the abstractions to assist you to improve the physical device. If you can understand the reports, you can improve things, either altering the RTL or adding more constraints.
The point being that the only time RTL is actually run like a software program is during simulation. This simulation is only an approximation of how the actual thing will work. It is not like SW. The tools do a lot of other things with that RTL. Maybe if people don't throw garbage in, it wont crap itself trying to figure it all out.
After synthesis, your RTL becomes a gate level representation. You then place your logic i.e. Your memory logic near your memories, I/O logic near your pins etc. You then make clock trees for your various clocks. You don't want related logic clocked by different parts of the clock tree. Once you have stuff physically located, you back annotate and do your static timing analysis.
You generally run simulation on the different stages of synthesis. Someone has to debug all these simulations. They never just pass.
There is a big difference between RTL and gate level simulation. A test passing in RTL is only the 1st stage. RTL doesn't have any wire models so no delays are in there. Gate level sims can run with delays in there.
Synthesis tools can also tell you it doesn't pass timing through static timing analysis but asynchronous parts of the design can't be analyzed. You need simulation there!
As someone in the industry, I would have to disagree. I question this every time someone claims it's so awesome. None of those solutions can run simulations on the back annotated netlist . How do you design without a simulation tool that can work at every stage of the design flow?
RTL is a behavioral model. Post synthesis is the physical model. What do you think synthesis engineers do? Just sit around watching the tools run?
Referring to pesticides: "Organic standards-setting bodies are responsive to new data on toxicity of natural substances and precautionary measured are applied while alternatives are being sought."
"most natural pesticides have a very small persistence in the environment and are, therefore, unlikely to be leave residues in food. Rotenone, for instance, breaks down when exposed to sunlight and has a short lifespan (a week or less) in the environment."
"Research is being undertaken to find alternatives to copper and, meanwhile, organic standards include restrictions on the quantity of copper salt applied to fields."