Block RAM simulation VII

Obviously because Verilog is inferior and you're being punished for your sins. >:_)

VHDL is the superior language, especially if you want carpel-tunnel syndrome.

Regards, Vinh

Ain't that the truth! The first part, I mean. :-)

Heh heh. Time to start a VHDL vs. Verilog flame war :_)

Page 155 of the manual...oh I see, it's talking about having XST implicitly infer a block ram from your HDL code. Hmm I don't know Verilog, but I would assume it'd have the ability to initialize the values of an array, similar to VHDL. But even if it doesn't, you would think they can pass initialization information through another mechanism, even perhaps through a specially formatted comment section.

It's probably the usual "not enough people to implement all the features we'd want; and not enough customers, or big customers, complaining about it."

I suppose you could always go through CoreGen/explicite declaration of BlockRAM route, and use it to initialize your ram. The contents would be easy to modify, when it comes to simulation at least, since it uses a text file (.MIF) to get the values. I'm not sure about the real hardware though. The values might be embedded in the EDIF, which would be a bit more of a hassle to modify.

In either case, you don't have the values handy inside of your Verilog code. I guess you could write a Perl script that looks for a specially formattted comment section in your Verilog, and then modify the EDIF.

Just another reason why VHDL is better ;_)

Actually I haven't used Verilog so I can't make an informed opinion...but then again, that's never stopped people before!

Regards, Vinh

Don't feel like doing that. But, clearly there are very compelling reasons to use VHDL for synthesis if you go beyond plain-vanilla pushbutton designs. Part of it might be due to the folks involved in writing the standards, I learned about this in the Verilog NG ... it was like talking to someone from another planet.

implicitly

I don't really use inference for these constructs, I instantiate explicitly. Why would you speak Greek when you know you need to say something in French and you can speak French? Maybe 'cause I'm old school ... I still have my auto-stripping electric wire-wrap gun.

No, I was just doing the usual "look through every manual to see why this isn't working" routine. That was the only reference I found on this question.

Hi, I think it does. If in ISE Project Navigator you go to Edit -> Language Templates ->

(in

No, not instantiation for synthesis. Simulation. That's why the subject is "Block RAM simulation VII". Initializing for synthesis works very well.

If you don't see what I quoted on page 155 of your XST User Guide check the document version. I have 4.0, issued on 06/06/03. It's what came with the latest ISE update.

Also, don't use the message subject line as part of a reply, it destroys a thread.

from

Heh heh :_D

explicitly.

French

You definately don't have to worry about the synthesis tools getting too creative. Inference can save you some typing, but spend some time with "generics" and "generate" and you can craft a piece of reusable code that can handle varying widths and depths. And though I've never tried it, doing RPMs might be easier with instantiation, since you have more control over the structure/naming of the components.

I just use inference because of the "neato" factor when I was first learning VHDL.

Heh I think I've only used it once, during an internship. Iy does a very nice and neat job though. I remember the experienced guys telling me war stories of having to wire up an entire board, only to find out they did something wrong under serval layers of other wiring.

is

Heh looks like I might have led Adarsh astray with my synthesis/simulation mix up. Oh how history repeats itself.

Hey Martin, sorry about the subject line. I am new to this newsgroup thing... i had an earlier version of XST. anyways, i see your point. if it is simulation you are talking about, do you mean functional simulation ? in that case how is XST connected to it ? and then is it really a verilog issue ? for simulation can't you just use the "initial" statement ? and for any post synthesis simulation, I think the example in language templates works. adarsh

is

the

the

No problem. That's why I pointed it out.

It's about simulating a Block RAM with data in it. Say you are using one as a lookup table. You want to run a simulation with the lookup table actually working, otherwise the results might be of little use.

I'll look into some of the other options. I sort of let this one go as verification was done in actual hardware. Can't stop to do it right, gotta keep that productivity up! :-)

:I don't really use inference for these constructs, I instantiate explicitly. :Why would you speak Greek when you know you need to say something in French :and you can speak French? Maybe 'cause I'm old school ... I still have my :auto-stripping electric wire-wrap gun.

Portability. An instantiated primitive locks you into that vendor's technology.

explicitly.

French

my

This is an often quoted reason to do many things.

In my humble opinion --and particularly with high performance designs-- I see nothing wrong with HDL that is vendor-specific. Actually, high performance designs almost mandate this approach. The idea of jumping from one vendor to another is, again, my opinion, a fallacy for but the most trivial pushbutton-process designs. I mean, just the cost of designing and spinning a new board (with all associated risks) is enough to preclude one from making this move.

One could, I suppose, argue that you'd build an HDL library that could be reused across designs or projects, regardless of the device or vendor. Again, I have a feeling that this is a part of reality only for JBOFF (just a bunch of flip-flops) designs. The minute you start to take advantage of device/vendor specific resources all bets are off. If you have to write device-specific descriptions to shove inference in the right direction you might as well use explicit instantiation.

One variation on that theme, of course, would be writing intelligent VHDL code that would allow you to tell the HDL what sort of a device the module in question will be synthesized for. The code would make the appropriate changes to fit the device. But, again, this is device-specific code, as it would have to contain that specific intelligence.

Yeah I agree with that, when it comes to high performance designs. In order to squeeze every bit of performance out of our FPGAs, we have to take advantage of specific architectural features. And since we're always on the cutting edge of performance, we have completely new hardware for each evolution of our product, so we rarely have code reuse (that's why I like the concept of Design Patterns which advocates architecture reuse instead of code reuse).

If one really wanted to be vendor independent, you would keep your design generic, lose performance in the design itself, and gain your performance by buying expensive chips and using more of them, but commercial projects are usually too price conscious to do that. Also we're always pushing the limits, so we tend to buy the highest end chips anyways. We can't upgrade any further.

But yeah, if you're not at the bleeding edge (or at least your particular piece of reusable code isn't high performance, like a CPU interface), and there's a high chance that your code would actually be reused, then inference can be handy. As with all things, it depends on your situation.

Hmm I was thinking about the meaning of "high performance" a bit while walking to my doctor's appointment (dang wife borrowed the car today, and she's always right). An FPGA design doesn't have to be high performance, relative to similar products, in order to require intimate knowledge and use of a specific FPGA architecture. What matters is how much performance you need, relative to the performance that the FPGA can provide without much design effort.

Since most commercial projects are price conscious, we're usually picking the cheapest FPGAs that don't cause us too much pain. Instead of paying the recurring cost of a more expensive bill of materials, management prefers spending a little more on design effort which only has a one time cost...well that's not totally true since there are hidden costs in choosing cheaper FPGAs that are harder to work with...but decissions are usually made on the more immidiate and visible costs.

So more often than not, we have to sacrifice vendor independence in order to squeeze more performance out of cheaper parts.

Vinh

Indeed - and no different to a lot of embedded software. Some will be in "vendor-specific" assembly, or even if in C, the low level stuff is not trivially portable!

I wonder if the difference is that in FPGA space there is a very limited choice of vendors, so some people may think that it is reasonableo t aim for vendor independance, whereas in the embedded processor space there are many more choices, so its clear you'll never cover them all!

Cheers, Martin

I aggree Martin. Embedded folks have to milk their processors for all they're worth also. I suppose there's so much similarity between hardware and embedded software, because they're just different ways of tackling the same problems.

Heh I bet. Each vendor has their own unique architecture and instruction set. Heck, there's a lot of differences between processor families from the same vendor.

That makes sense. The non-embedded world has two large players, the x86 and PowerPC. The FPGA world has two big players also.

Heh yeah, it's better to know that something is futile, so you don't waste your time.

Regards, Vinh