gluggymug · HackerTrans

I believe Tcl scripts can help automate your FSBL and BSP changes. Pretty much everything you do in the GUI translates to Tcl commands.

gluggymug

9 anni fadiscuss

There is a distinction between hardware emulators and FPGAs. Though hardware emulators such as Palladiums may use FPGAs inside them they don't work the same way in terms of validation. The two tools are very different to use.

See myth 7 here: http://www.electronicdesign.com/eda/11-myths-about-hardware-...

gluggymug

9 anni fadiscuss

At the SoC level, I don't think so.

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.

gluggymug

9 anni fadiscuss

"If you're Intel or AMD making a processor, I bet FPGA versions of things are not terribly relevant because it doesn't capture a whole host of physical effects at the bleeding edge."

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.

gluggymug

9 anni fadiscuss

I don't agree. If it's non trivial, I don't have the more advanced verification tools such as UVM if I prototype via FPGA.

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.

gluggymug

9 anni fadiscuss

As a veteran from the chip industry, I should warn you that all these suggestions about FPGAs for prototyping are not really done that much in the ASIC industry.

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.

gluggymug

9 anni fadiscuss

I say "terribly-designed curriculum".

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.

gluggymug

9 anni fadiscuss

If you are not an old fart like myself, you probably haven't used an actual Unix system but back in the days before the popularity of Linux, you'd see a lot of Solaris.

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.

gluggymug

9 anni fadiscuss

It's the experimental part of the high level language that is the problem. I agree you shouldn't teach it to students. It just leads them down a divergent path away from what is done in industry. It isn't addressing the needs of the student, only their short term "wants".

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.

gluggymug

9 anni fadiscuss

"One thing that bit me when I was a complete n00b: assigning registers from within more than a single always block. On my simulator (at the time) it worked perfectly but the synthesis tool silently ignored one of the blocks."

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.

gluggymug

9 anni fadiscuss

The problem is that reset logic requires a bit of design rather than hard fast rules.

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.

gluggymug

9 anni fadiscuss

I agree about the parallelism but you have to understand the design methodology.

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.

gluggymug

9 anni fadiscuss

As a long time HW FPGA guy, I think you might want to take a look at the C projects again. I don't know whether Go has any advantages but the concept of a higher level language for development is being used by the major FPGA companies.

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.

gluggymug

9 anni fadiscuss

    >- jump to previous commands.
    >You just ran a command that printed a few pages, you want to scan from the first line.

I think tmux might get you there. You bind a key to enter copy-mode and backward search for your particular prompt.

    >- collapse previous outputs (stderr / stdout / both)
    > Let me toggle stdout / stderr after the command has been run.

That sounds like a good one.

    >- 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?

Once again tmux could "save-buffer" to a file for you if you did that backwards search then copy to a paste buffer. Just bind another key.

gluggymug

9 anni fadiscuss

>Lack of electronics knowledge is what prevents most software developers from being productive in Verilog. A "better" language won't help.

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.

gluggymug

9 anni fadiscuss

How long have you had your current job?

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.

gluggymug

9 anni fadiscuss

A few years ago there was an exposé on 457 abuse in the IT industry on national tv.(http://www.abc.net.au/7.30/content/2013/s3786315.htm)

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.

gluggymug

9 anni fadiscuss

The OA is talking a bit more specifically than just getting kids to play IMO. His title is Head of Innovation.

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.

gluggymug

9 anni fadiscuss

I think CASE 3 is going to be much faster due to the high performance AXI ports that Zynq's have.

gluggymug

9 anni fadiscuss

Cool project.

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.

comments