Block RAM simulation VII

[Martin Euredjian]

Page 155, XST User guide:

"XST does not support block RAM initialization in Verilog."

Why not?

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"

 

[Vinh Pham]

"XST does not support block RAM initialization in Verilog."

Why not?

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

 

[Martin Euredjian]

"Vinh Pham" wrote:

"XST does not support block RAM initialization in Verilog."

Why not?

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

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


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"

 

[Vinh Pham]

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

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

 

[Martin Euredjian]

"Vinh Pham" wrote:

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

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.

Page 155 of the manual...oh I see, it's talking about having XST
implicitly
infer a block ram from your HDL code.

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.


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"

 

[Adarsh Kumar Jain]

Hi,
I think it does.
If in ISE Project Navigator you go to Edit -> Language Templates ->
Verilog -> Component Instantiation, then you can see the way it is done (in
any of the RAM instantiation samples).
Please do correct me if I am making some mistake.
Adarsh
"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:2u8Ab.66158$PY.31048@newssvr25.news.prodigy.com...

Page 155, XST User guide:

"XST does not support block RAM initialization in Verilog."

Why not?

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"

 

[Martin Euredjian]

"Adarsh Kumar Jain" wrote:

Verilog -> Component Instantiation, then you can see the way it is done
(in
any of the RAM instantiation samples).

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.


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"

 

[Vinh Pham]

learned about this in the Verilog NG ... it was like talking to someone
from
another planet.

Heh heh :_D

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

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.

I still have my auto-stripping electric wire-wrap gun.

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.

 

[Vinh Pham]

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

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

 

[Adarsh Kumar Jain]

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




"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:tlBAb.66747$aJ6.11966@newssvr25.news.prodigy.com...

"Adarsh Kumar Jain" wrote:

Verilog -> Component Instantiation, then you can see the way it is done
(in
any of the RAM instantiation samples).

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.


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"

 

[Martin Euredjian]

"Adarsh Kumar Jain" wrote:

sorry about the subject line. I am new to this newsgroup thing...

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

do you mean functional simulation

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!


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"

 

[David R Brooks]

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote:

: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.

 

[Martin Euredjian]

"David R Brooks" wrote:

: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.

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.



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"

 

[Vinh Pham]

In my humble opinion --and particularly with high performance designs-- I

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.

 

[Vinh Pham]

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

 

[Martin Thompson]

"Vinh Pham" <a@a.a> writes:
<snip>

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

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

--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

 

[Vinh Pham]

Indeed - and no different to a lot of embedded software. Some will be

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.

in "vendor-specific" assembly, or even if in C, the low level stuff is
not trivially portable!

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.

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

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

processor space there are many more choices, so its clear you'll never
cover them all!

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


Regards,
Vinh