J
Jonathan Bromley
Guest
In a recent thread "True dual-port RAM in VHDL: XST question"
I claimed that, in my tests, I had found XST tolerating
a bad description of dual-port dual-clock RAM.
**********************************************
I WAS COMPLETELY WRONG in my criticism of XST.
**********************************************
Apology first, then the details.
*****************************************
I hope Xilinx will accept my sincere
apology for wrongly describing a problem
that in fact does not exist in their tool.
Thanks to the WebCase team for responding
promptly and courteously to my inappropriate
bug report.
*****************************************
I was right about the VHDL; the template I described
(two processes writing to the same signal) is indeed
a bad description of a RAM, and should not be tolerated
for synthesis.
I was wrong to say that XST accepts it. It simply doesn't.
Way back, certainly since version 8.2, XST has got this
right; it rejects the bad code with a helpful diagnostic.
So, how did I get this so badly wrong?
I was trying out a very large number of different RAM
models on a very large number of different tools, so of
course I wrote a script to drive synthesis. For some
reason that I still don't understand, when I compiled
first a Verilog version and then a VHDL version of the
same design, XST was processing the compiled results
from the Verilog code on both occasions (even though
the first few lines of the report file told me, as
expected, that it was compiling the VHDL file second
time around). Consequently I thought the bad VHDL
version was getting through, when in fact it was
the (correct) Verilog code that was being processed.
Very, very careful and thorough clean-out of working
directories was required to get the VHDL version
to be compiled - and to throw the error.
A nasty case of "back to the drawing board".
It should also be noted that XST does indeed correctly
synthesize dual-clock RAM from a shared-variable model.
So, retreating from Xilinx with tail firmly between
legs, I shall saddle up the old warhorse and ride it
in the direction of a different vendor....
One final point: why, one might ask, did I go to
Usenet first, rather than to Xilinx direct, when
I found the problem? Simply because I didn't want
to go to Xilinx with a spurious bug report, and I
hoped to calibrate my own understanding against
others. Yet another well-meaning plan backfires...
--
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.
I claimed that, in my tests, I had found XST tolerating
a bad description of dual-port dual-clock RAM.
**********************************************
I WAS COMPLETELY WRONG in my criticism of XST.
**********************************************
Apology first, then the details.
*****************************************
I hope Xilinx will accept my sincere
apology for wrongly describing a problem
that in fact does not exist in their tool.
Thanks to the WebCase team for responding
promptly and courteously to my inappropriate
bug report.
*****************************************
I was right about the VHDL; the template I described
(two processes writing to the same signal) is indeed
a bad description of a RAM, and should not be tolerated
for synthesis.
I was wrong to say that XST accepts it. It simply doesn't.
Way back, certainly since version 8.2, XST has got this
right; it rejects the bad code with a helpful diagnostic.
So, how did I get this so badly wrong?
I was trying out a very large number of different RAM
models on a very large number of different tools, so of
course I wrote a script to drive synthesis. For some
reason that I still don't understand, when I compiled
first a Verilog version and then a VHDL version of the
same design, XST was processing the compiled results
from the Verilog code on both occasions (even though
the first few lines of the report file told me, as
expected, that it was compiling the VHDL file second
time around). Consequently I thought the bad VHDL
version was getting through, when in fact it was
the (correct) Verilog code that was being processed.
Very, very careful and thorough clean-out of working
directories was required to get the VHDL version
to be compiled - and to throw the error.
A nasty case of "back to the drawing board".
It should also be noted that XST does indeed correctly
synthesize dual-clock RAM from a shared-variable model.
So, retreating from Xilinx with tail firmly between
legs, I shall saddle up the old warhorse and ride it
in the direction of a different vendor....
One final point: why, one might ask, did I go to
Usenet first, rather than to Xilinx direct, when
I found the problem? Simply because I didn't want
to go to Xilinx with a spurious bug report, and I
hoped to calibrate my own understanding against
others. Yet another well-meaning plan backfires...
--
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.