Clock Edge notation

[rickman]

On Jun 24, 7:44 am, "Fredxx" <fre...@spam.com> wrote:

"Jonathan Bromley" <jonathan.brom...@MYCOMPANY.com> wrote in message

news:bn0445lbemmf3qnl87te1hps2l3nc9novv@4ax.com...



On Wed, 24 Jun 2009 11:37:24 +0100, "Fredxx" wrote:

if you used something like;
     if we1 = '1' then
       mem(to_integer(unsigned(a1))) := wd1;
     else
       mem(to_integer(unsigned(a1))) := (others => 'Z');
     end if;

Would this then give more consistent results where both processes wouldn't
be fighting against each other?

Sadly, no.  I see what you're getting at, but I don't think you could
ever get the memory to have the correct contents if both ports are
doing that all the time.  Each process may overwrite locations it's
already correctly written, using Zs, for no good reason.

Suppose you could get it right somehow, and arrange that each process
is driving Z to all locations it's never written, but appropriate
values to locations it has written.  What then happens if the second
process writes to a location that previously was written by the other?
How can it tell the first process now to put Z on that location?

In truth the "correct" solution would be to write the whole thing
as a single process with two clocks:

 process (clock0, clock1)
   variable mem: t_mem;
 begin
   if rising_edge(clock0) then
     if we0 = '1' then
       mem(a0) := wd0;
     end if;
   end if;
   if rising_edge(clock1) then
     if we1 = '1' then
       mem(a1) := wd1;
     end if;
   end if;
   ...

But I suspect synthesis tools would chuck that overboard
without a second thought.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

I perhaps am making the (erroneous) assumption that two statements will be
or'd together and the Z's will be overdriven by the signals.  But as you
say, I would be replacing the RAM locations with Z's or something that the
synthesiser concocts.

To be honest, I think it isn't good practice to have signals driven by 2
clocks, and I'd probably use clock switching primitives instead so the
memory would be written in one process with just one clock.

That would be a truly bizarre circuit design. I don't know how they
actually construct memory to use separate clocks, but I expect it uses
an async memory with two independent synchronous interfaces. FPGA
reps have posted here that there is a lot of "magic" in the logic
between the sync interfaces and the async memory inside the block
ram. All of this would be very hard to describe using an HDL. But
driving a signal with 'z' or switching clocks is not the way to go at
all...

Rick

 

[Muzaffer Kal]

On Wed, 24 Jun 2009 16:27:30 +0100, "Fredxx" <fredxx@spam.com> wrote:

The asynchronous memory is an array of flip-flops rather than a memory, but
that's a mute point. It does both synthesise and simulate in Xilinx ISE
tools.

Flip-flops need a clock to function. How do you write to them without

a clock to implement asynchronous memory (which by definition doesn't
have it?). You can use an array of latches as opposed to flip-flops
but timing latches is quite difficult especially in an fpga context
where tools are really not geared towards it. You maybe able to
synthesize it in ISE and the original code simulates for sure but have
you tried a back-annotated gate level simulation? It would be an
interesting challenge to get it to work fully unless your read/write
pulse widths and separations are extremely conservative.
One last to remember is that there are a lot fewer slice registers
(from which latches are made) than memory bits in an FPGA so you're
quite limited in how much async memory of this type you can make.
---
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com

 

[rickman]

On Jun 24, 10:45 am, "Fredxx" <fre...@spam.com> wrote:

"Jonathan Bromley" <jonathan.brom...@MYCOMPANY.com> wrote in message

news:e76445hlo55p6dki0oi764adcblv5oloul@4ax.com...



On Wed, 24 Jun 2009 12:44:27 +0100, "Fredxx" wrote:

I perhaps am making the (erroneous) assumption that two statements will be
or'd together and the Z's will be overdriven by the signals.

That's more-or-less correct.  Each process represents a driver
on any signal it writes.  If multiple processes write to a signal,
then the actual signal value is determined by resolving the
various driven values.  Of course, anything else overdrives Z.

The hard-to-solve problem:  suppose process A writes a value
to a memory location at some time; clearly, you want that
value to remain in the location and not to be overwritten
to Z on the next clock, so you can't allow process A to change
its mind about that value.  Some time later, suppose process B
writes to the same location.  Now you have two non-Z drivers
on the same set of bits.  How can process B tell process A
that it's time for its driver to lapse back to Z?  Shared
variables, for all their ugliness, solve this problem
neatly (which is why my problem simply doesn't exist in
Verilog, where all variables are shared).

To be honest, I think it isn't good practice to have signals driven by 2
clocks, and I'd probably use clock switching primitives instead so the
memory would be written in one process with just one clock.

In normal logic I would 100% agree, but here I'm talking about
modeling and synthesizing the FPGAs' built-in RAM blocks, which
have the option of independent clocks on the two ports.  So
it is important to write VHDL corresponding to that behavior.
You could mux the clocks onto a single port, but that would
be a totally different design.

What's wrong with an asynchronous memory, where the appropriate clocks latch
the control signals to create synchronous RAM.

Then we can do something like:

process (a0, we0, wd0, a1, we1, wd1)
begin
  if we0 = '1' then  -- write to port A
    mem(conv_integer(a0)) <= wd0;
  end if;
  if we1 = '1' then  -- write to port A
    mem(conv_integer(a1)) <= wd1;
  end if;
  rd0 <= mem(conv_integer(a0));
  rd1 <= mem(conv_integer(a1));
end process;

It works in simulation!!

I doubt that it will synthesize. Synthesis is largely a matter of
template matching. You can describe a behavior any way you want in
simulation. But if the synthesis tool does not recognize that form,
it won't synthesize to anything useful. Often memory that is not
recognized as a block ram is synthesized as distributed memory using
much of the FFs on a chip. Not only that, but it takes forever to
complete just to find out you don't have a workable design.

Rick

 

[Sandro]

On Jun 24, 2:23 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>

...
In normal logic I would 100% agree, but here I'm talking about
modeling and synthesizing the FPGAs' built-in RAM blocks, which
have the option of independent clocks on the two ports.  So
it is important to write VHDL corresponding to that behavior.
You could mux the clocks onto a single port, but that would
be a totally different design.
...

If you are curious please take a look to the vhdl VITAL
simulations sources...
you can find in

<ISE INST PATH>/Xilinx/10.1/ISE/vhdl/src/unisims/unisim_VITAL.vhd

but be careful ;-) ... they are NOT 20 lines of code.

Regards
Sandro

 

[Jonathan Bromley]

On Wed, 24 Jun 2009 08:31:26 -0700 (PDT), Sandro wrote:

If you are curious please take a look to the vhdl VITAL
simulations sources...

I know about the vendor-provided simulation models,
which are fine pieces of work that do their job well.
But they are completely irrelevant both to my original
problem and to the issue I asked about.

I'm trying to assemble a complete and accurate list
of the _synthesizable_ templates for all common types
of FPGA memory, and I have discovered a template
that synthesizes to dual-clock RAM in two FPGA
vendors' tools but is a complete nonsense for
simulation. I want to know why this has happened,
what we can do about it, and why the vendors haven't
already been beaten to pulp over it by users.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Jonathan Bromley]

On Wed, 24 Jun 2009 10:53:49 -0700 (PDT), Andy wrote:

[of multi-clocked processes in VHDL]

Current synthesis tools would probably have an issue with this, but
there's no good reason for it. DDR synthesis (though not the same as
independent clock, dual port memories) needs it anyway.

I completely agree. One of the side-effects of the
survey I'm doing will probably be that I'll log requests
for exactly this feature with all the synthesis vendors.
I don't hold out much hope, though. Support welcomed ;-)
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Muzaffer Kal]

On Wed, 24 Jun 2009 18:57:29 +0100, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

I'm trying to assemble a complete and accurate list
of the _synthesizable_ templates for all common types
of FPGA memory, and I have discovered a template
that synthesizes to dual-clock RAM in two FPGA
vendors' tools but is a complete nonsense for
simulation. I want to know why this has happened,
what we can do about it, and why the vendors haven't
already been beaten to pulp over it by users.

Originally coming from ASIC side I find this incredible but it seems
that majority of people doing FPGA design don't simulate. I was at an
FPGA infomercial the other day about two new device families coming
out from a vendor to stay nameless and only %20 or so people raised
their hands when asked this question. This might explain how these
templates survived as is for such a long time.
---
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com

 

[Mike Treseler]

Jonathan Bromley wrote:

I'm trying to assemble a complete and accurate list
of the _synthesizable_ templates for all common types
of FPGA memory, and I have discovered a template
that synthesizes to dual-clock RAM in two FPGA
vendors' tools but is a complete nonsense for
simulation. I want to know why this has happened,
what we can do about it, and why the vendors haven't
already been beaten to pulp over it by users.

This has happen because the majority of FPGA
designers prefer to wire together blocks
by others, and verify on the bench using
trial and error synthesis.

The silly dual clock RAM model is ignored
not because it is silly, but because
a vendor netlist is preferred to RTL
to get at all the asynchronous black magic.

What to do? I stick with single clock RAMs
and arbitrate synchronously.

-- Mike Treseler

 

[Fredxx]

"Muzaffer Kal" <kal@dspia.com> wrote in message
news:4ul445tbv9klgrceumj15dd2jfcpjp4raq@4ax.com...

On Wed, 24 Jun 2009 16:27:30 +0100, "Fredxx" <fredxx@spam.com> wrote:
The asynchronous memory is an array of flip-flops rather than a memory,
but
that's a mute point. It does both synthesise and simulate in Xilinx ISE
tools.

Flip-flops need a clock to function. How do you write to them without
a clock to implement asynchronous memory (which by definition doesn't
have it?). You can use an array of latches as opposed to flip-flops
but timing latches is quite difficult especially in an fpga context
where tools are really not geared towards it. You maybe able to
synthesize it in ISE and the original code simulates for sure but have
you tried a back-annotated gate level simulation? It would be an
interesting challenge to get it to work fully unless your read/write
pulse widths and separations are extremely conservative.
One last to remember is that there are a lot fewer slice registers
(from which latches are made) than memory bits in an FPGA so you're
quite limited in how much async memory of this type you can make.

Different types of flip flops can be inferred by VHDL. Not all have to use
the global clock, or even a clock as such.

True - if it was my problem, I would look at the logic it creates, but at
the moment I don't have time.

 

[Andy]

On Jun 24, 6:15 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

In truth the "correct" solution would be to write the whole thing
as a single process with two clocks:

  process (clock0, clock1)
    variable mem: t_mem;
  begin
    if rising_edge(clock0) then
      if we0 = '1' then
        mem(a0) := wd0;
      end if;
    end if;
    if rising_edge(clock1) then
      if we1 = '1' then
        mem(a1) := wd1;
      end if;
    end if;
    ...

But I suspect synthesis tools would chuck that overboard
without a second thought.

Current synthesis tools would probably have an issue with this, but
there's no good reason for it. DDR synthesis (though not the same as
independent clock, dual port memories) needs it anyway. Some synthesis
tools support dual clock processes, just not writes to the same var/
sig on both clocks. The only time this example does not behave like a
true dual clock/port ram is when two writes are attempted to the same
address at exactly the same time, which is not even defined for the
real HW. Good system design makes that case meaningless anyway.

Andy

 

[Andy Peters]

On Jun 24, 10:57 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

I'm trying to assemble a complete and accurate list
of the _synthesizable_ templates for all common types
of FPGA memory, and I have discovered a template
that synthesizes to dual-clock RAM in two FPGA
vendors' tools but is a complete nonsense for
simulation.  I want to know why this has happened,
what we can do about it, and why the vendors haven't
already been beaten to pulp over it by users.

The vendors say, "Instantiate the component from the library," which
neatly sidesteps the difficult work of actually enabling such
inference.

-a

 

[Alex]

On Jun 24, 10:57 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Wed, 24 Jun 2009 08:31:26 -0700 (PDT), Sandro wrote:
If you are curious please take a look to the vhdl VITAL
simulations sources...

I know about the vendor-provided simulation models,
which are fine pieces of work that do their job well.
But they are completely irrelevant both to my original
problem and to the issue I asked about.  

I'm trying to assemble a complete and accurate list
of the _synthesizable_ templates for all common types
of FPGA memory, and I have discovered a template
that synthesizes to dual-clock RAM in two FPGA
vendors' tools but is a complete nonsense for
simulation.  I want to know why this has happened,
what we can do about it, and why the vendors haven't
already been beaten to pulp over it by users.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

The truth is that current FPGA Synthesis tools quite often do a poor
job (not counting trivial cases here) in inference of FPGA vendors'
macros. From the other hand FPGA vendors want users to instantiate
their macros (and so to be locked into their devices) and make it very
easy to configure and generate the code for instantiation using
proprietary vendor tools.
So majority of users prefers to instantiate the macros as a better
alternative to make the Synthesis tools infer the necessary structure
(and lose sometimes days on debugging different synthesis attributes,
directives etc...)
Just wanted to offer a possible explanation in answer to your
question, Jonathan :^)

Theoretically, independent FPGA synthesis tools vendors (Mentor,
Synopsys) should be interested for users to create a vendor
independent code. This way they'll have a much stronger case for multi-
vendor tools...

Alex Yourovski

 

[Martin Thompson]

Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> writes:

I completely agree. One of the side-effects of the
survey I'm doing will probably be that I'll log requests
for exactly this feature with all the synthesis vendors.
I don't hold out much hope, though. Support welcomed ;-)

You have mine!

And thanks for sharing the results of your investigations with us all!

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

 

[Nial Stewart]

Originally coming from ASIC side I find this incredible but it seems
that majority of people doing FPGA design don't simulate. I was at an
FPGA infomercial the other day about two new device families coming
out from a vendor to stay nameless and only %20 or so people raised
their hands when asked this question. This might explain how these
templates survived as is for such a long time.

Do you mean don't simulate the P&R'd design, or not at all?



Nial.

 

[sleeman]

On Jun 25, 6:55 am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:

Originally coming from ASIC side I find this incredible but it seems
that majority of people doing FPGA design don't simulate. I was at an
FPGA infomercial the other day about two new device families coming
out from a vendor to stay nameless and only %20 or so people raised
their hands when asked this question. This might explain how these
templates survived as is for such a long time.

Do you mean don't simulate the P&R'd design, or not at all?

Nial.

This thread has brought up several very interesting themes. I'd like
to add my two cents to each.

1) Synthesis templates for RAMS. I think what Jonathan is doing is a
great idea. I'd love to see a better definition of what cross-device
code patterns are safe to use and supported by which tools. From
experience, I can say that I've done it right for a few key designs,
and managed to leverage off of that by wrapping this inference in an
entity, giving me a device-independent (more-or-less) codebase but
still requiring structural coding around the RAM. It's not ideal by a
long shot. But by enforcing good version control discipline through
the organization and introducing a mindset that says "don't fiddle
around with a perfectly good library module, use it as-is or not at
all", we have managed to reduce the number of times designers sit
there, asking the same questions: "I only changed one line of code;
why did it start making distributed RAM? What were those attributes
again? When I don't use the read port how do I stop the synthesizer
from complaining?" and so on and so on.

2) Clocks versus asynchronous logic. My view of this is that clocks
are both an obvious physical thing (as anyone who flies a scope for
living well knows) as well as an abstraction. This abstraction is
what constitutes the "contract", or point of demarcation between high-
level circuit digital designer, and the guy who actually codes the
gate-level RAM and control logic. The job of the low-level transistor
guy is to provide a circuit that acts as if the clock abstraction is a
true representation of what actually happens inside. He may use flops,
latches, vernier timing thingies, or whatever the heck he needs. But
he *must* obey the clock-concept contract. The job of the high-level
(FPGA application developer) is to make use of the clock concept
abstraction in order to make his design synchronous, which implies
robustness, maintainability, and all the other virtues that regular
posters here know so well.

3) People who don't do simulation? Definitely. I've help manage the
change in an organization growing from a couple of FPGA guys to a
fairly well-oiled FPGA talent pool with established version control,
substantial as-is module re-use, and an ingrained mindset that a
modules doesn't get released without a scripted, regressionable
testbench. They're two points at opposite ends of a continuum of
process, but I see a lot of real work in industry done at both ends.

The "garage shop" FPGA approach typically has some guys who learned
VHDL in school, then got thrown into the deep end alone, or who "came
up through the ranks" from CPLDs and board design. No VC, no software
techniques, no libraries, packages, functions or elegant code in the
source. Hack job, in short. Two of these guys working on the same
project may often be running different tool versions, and not even be
able to load the design as-is from the other guy's sources, without a
lot of manual GUI fiddling to reset paths, manually link in the right
libraries, and so on. There's little chance of even building the same
design twice in a row. These are the guys who throw their bitfile onto
the board, and if it doesn't work, start writing some testbenches
(aww, do I *have* to do that... what a pain). They don't want to
simulate because its too hard/too long to sim the whole chip, and
because there's poor structure and/or modularity in their own code to
begin with, so it's also too hard to isolate a portion and make a
simple test for it, too.

The "pro" is at the other end of the continuum. Most of the regular
posters here try to answer the "garage guys" with answers that will
point them in the direction of becoming a "pro". It's a lot more
work, but there's a lot of benefit to being able to release a chip
that you know that anyone on your team can build again, bit/UCF/source-
accurately, when you're on vacation.

Of course, some "pros" work in garage shops. But the Big Tool (Big
Two?) vendors tend to cater most of their tools to the garage shop
guys. Everything can be set by clicking on a GUI button. Everything
about a project is stored in unreadable binary files. They try to
force you into their half-assed version control scheme, if they offer
one at all. How are you ever going to share designs or document them
for the future that way? And all of the "sex appeal" about the new
devices is put into the GUI, the new buttons that you can click on,
and the new auto-wizards (that don't usually have a mode to generate
output from anything other than unreliable, unrepeatable user mouse
clicks). ( I tend to think of this emphasis on sexy GUI tools leading
then to bad project practices as being akin to drug dealers pushing
crack in the schoolyards, but that would get me in trouble with my
local FAEs so I'll refrain

Don't get me wrong... I had a lot of fun as a garage guy myself. I
built some pretty damn fine hardware "back in the day" before I even
had the option of simulating my code. But I agree, there are still a
lot of guys who view testbenches and simulation as something painful
and only to be done if really necessary. In truth, it's like pretty
much everything else in life: you get out more when you put in more
work.

OK, I'm done ranting now

- Kenn

 

[Muzaffer Kal]

On Thu, 25 Jun 2009 07:33:06 -0700 (PDT), rickman <gnuarm@gmail.com>
wrote:

On Jun 24, 2:11 pm, Muzaffer Kal <k...@dspia.com> wrote:
On Wed, 24 Jun 2009 18:57:29 +0100, Jonathan Bromley

jonathan.brom...@MYCOMPANY.com> wrote:
I'm trying to assemble a complete and accurate list
of the _synthesizable_ templates for all common types
of FPGA memory, and I have discovered a template
that synthesizes to dual-clock RAM in two FPGA
vendors' tools but is a complete nonsense for
simulation.  I want to know why this has happened,
what we can do about it, and why the vendors haven't
already been beaten to pulp over it by users.

Originally coming from ASIC side I find this incredible but it seems
that majority of people doing FPGA design don't simulate. I was at an
FPGA infomercial the other day about two new device families coming
out from a vendor to stay nameless and only %20 or so people raised
their hands when asked this question.

I missed something. What question exactly?

Whether they simulate their designs, (before downloading & testing on
the board).
-
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

 

[rickman]

On Jun 24, 2:11 pm, Muzaffer Kal <k...@dspia.com> wrote:

On Wed, 24 Jun 2009 18:57:29 +0100, Jonathan Bromley

jonathan.brom...@MYCOMPANY.com> wrote:
I'm trying to assemble a complete and accurate list
of the _synthesizable_ templates for all common types
of FPGA memory, and I have discovered a template
that synthesizes to dual-clock RAM in two FPGA
vendors' tools but is a complete nonsense for
simulation.  I want to know why this has happened,
what we can do about it, and why the vendors haven't
already been beaten to pulp over it by users.

Originally coming from ASIC side I find this incredible but it seems
that majority of people doing FPGA design don't simulate. I was at an
FPGA infomercial the other day about two new device families coming
out from a vendor to stay nameless and only %20 or so people raised
their hands when asked this question.

I missed something. What question exactly?

Rick

 

[Jonathan Bromley]

On Thu, 25 Jun 2009 11:11:59 -0700 (PDT), rickman wrote:

Are engineers the stupidest people in the world

No, I don't think so. I meet loads of engineers in
my training work, and it is rare indeed to find a
stupid one. Some are quite extraordinarily smart.

However, engineers do very complicated, occasionally
very difficult, and certainly very arcane things.
I reckon they get used to the idea that no-one they
meet is likely to be able to help them much. So
they get very narrowly focused on the (perceived)
task at hand, and lose the ability to look outside
their narrow concerns. (I'm sure I fall into that
trap frequently myself.) That narrowness can
easily come across as arrogance and/or reluctance
to accept advice.

Getting software folk and digital designers
talking to each other would be a big step in
the right direction. Sometimes that works well,
but certain project management styles (as in Rick's
story) go a long way towards preventing it.

Re-skilling, as often as you get the chance, is
a pretty good antidote to belief that you know
it all. Career circumstances don't usually make
that easy to do, sadly.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[rickman]

On Jun 25, 11:44 am, Muzaffer Kal <k...@dspia.com> wrote:

On Thu, 25 Jun 2009 07:33:06 -0700 (PDT), rickman <gnu...@gmail.com
wrote:



On Jun 24, 2:11 pm, Muzaffer Kal <k...@dspia.com> wrote:
On Wed, 24 Jun 2009 18:57:29 +0100, Jonathan Bromley

jonathan.brom...@MYCOMPANY.com> wrote:
I'm trying to assemble a complete and accurate list
of the _synthesizable_ templates for all common types
of FPGA memory, and I have discovered a template
that synthesizes to dual-clock RAM in two FPGA
vendors' tools but is a complete nonsense for
simulation.  I want to know why this has happened,
what we can do about it, and why the vendors haven't
already been beaten to pulp over it by users.

Originally coming from ASIC side I find this incredible but it seems
that majority of people doing FPGA design don't simulate. I was at an
FPGA infomercial the other day about two new device families coming
out from a vendor to stay nameless and only %20 or so people raised
their hands when asked this question.

I missed something.  What question exactly?

Whether they simulate their designs, (before downloading & testing on
the board).

Oh, I see. The last place I worked was a pretty good sized defense
contractor making push to talk radios. They actually had the FPGA
group under the software department because they felt it has more in
common (such as using version control on the source files). I was in
the hardware group and so not allowed to work on anything in the FPGA,
including code to test my hardware. One of the other "hardware"
engineers gave a "training" lecture to the entire hardware department
(most of who were RF designers) about FPGA design. His method of
doing timing analysis was to run a simulation!!! I had to stop him
right there are point out that was what static timing analysis was
for. He said that was not needed, since he could do a post route
simulation. How insane is that!!!!!????

The other side of the coin was that they had a newbie working the FPGA
code which was a collection of a couple of UARTs, I2C and a custom
serial interface. Instead of simulating (or maybe just not a very good
simulation) they were relying on the Xilinx logic analyzer tool. I
can't think of a more painful way of doing the initial debug. I was
asked to help them get the FPGA to load a bit file the first time and
they didn't want to listen much to me. They had five (yes FIVE!!!)
engineers working on it including a very senior engineer and a first
level manager. No one could seem to figure out what was wrong. I had
to wedge my way into the fray and started showing them the few simple
steps you have to take to get it going. I kept pointing out that you
need to give a few extra clocks at the end of downloading the file to
get the part out of configuration mode and they kept telling me that
was already tried. But the symptoms all pointed to this as the
problem. So I had to beat on it over and over again until finally
someone realized that they had tried adding strobes up to 64k as a
magic bullet and when that didn't make it work (they had more than one
problem) it was removed entirely! So they finally listened to me for
a moment and the devices loaded... FIVE engineers couldn't figure
that out!!!

So we have engineers who don't believe it is productive to run
simulation, engineers who believe they don't need to use static timing
analysis and engineers who can't debug their way out of a paper bag!!!

Are engineers the stupidest people in the world or is it just defense
contractors?

Rick

 

[Fredxx]

"Muzaffer Kal" <kal@dspia.com> wrote in message
news:csq445t6012cnufggai343t9jqptbe2pnd@4ax.com...

On Wed, 24 Jun 2009 18:57:29 +0100, Jonathan Bromley
jonathan.bromley@MYCOMPANY.com> wrote:

I'm trying to assemble a complete and accurate list
of the _synthesizable_ templates for all common types
of FPGA memory, and I have discovered a template
that synthesizes to dual-clock RAM in two FPGA
vendors' tools but is a complete nonsense for
simulation. I want to know why this has happened,
what we can do about it, and why the vendors haven't
already been beaten to pulp over it by users.

Originally coming from ASIC side I find this incredible but it seems
that majority of people doing FPGA design don't simulate. I was at an
FPGA infomercial the other day about two new device families coming
out from a vendor to stay nameless and only %20 or so people raised
their hands when asked this question. This might explain how these
templates survived as is for such a long time.

At the same time blind reliance of simulators is just as bad. There is the
old saying garbage in = garbage out. Personally I choose a mix as an early
misunderstanding can otherwise waste an inordinate amount of time.

In the past I have also come across instances where simulation has taken so
long, and created such large files, that reality has been quicker with a few
debugging flags in the code!

Each to their own.