EDK : FSL macros defined by Xilinx are wrong

[Peter Alfke]

The mercury delay lines were earlier, and were used only in
"mainframes" of that day. Who wants to have a pot full of mercury
sloshing around in a cash register? But this was before environmental
concerns, when leaded gasoline was the best thing ever...

Did anybody mention the Williams tube? A CRT where you wrote to and
read from the tube face.
It got killed by the early core memories, which in turn lived much
longer than anybody had expected. Non-volatile storage with destructive
read-out, just the opposite of SRAM nowadays.
Peter
Peter

 

[Jim Granville]

Peter Alfke wrote:

The mercury delay lines were earlier, and were used only in
"mainframes" of that day. Who wants to have a pot full of mercury
sloshing around in a cash register? But this was before environmental
concerns, when leaded gasoline was the best thing ever...

Did anybody mention the Williams tube? A CRT where you wrote to and
read from the tube face.
It got killed by the early core memories, which in turn lived much
longer than anybody had expected. Non-volatile storage with destructive
read-out, just the opposite of SRAM nowadays.

You could say core memory still lives on : in FRAM devices = identical
property of magnetic domain storage with destructive read - only they
are now manufactured on a wafer, with additional process steps to insert
the magnetic domain material, instead of physically wired.
[ Bubble memory seems to have hit an evolutionary dead end..]

I also see Intel reckons Ovionic (phase change) memory might yet fly...

-jg

 

[Allan Herriman]

On 13 Mar 2006 06:18:28 -0800, "vssumesh" <vssumesh_asic@yahoo.com>
wrote:

In the 9th page of VirtexE user guide ds022.pdf it is said that the
VirtexE LUTs can be used as 16x1 RAM. How can an LUT be used as RAM. I
think the content of the LUT is written at the time of burning the
FPGA. Is this an error or is there any way we can change the
configuration of the LUT dynamically.

This is not an error. The four input LUT consists of 16 memory
locations, the value of which is loaded from the configuration
bitstream. It can be configured in a number of modes:

- LUT. This is like a 16 entry ROM.
- RAM. Like the LUT, but with the ability to write a bit to a
location.
- SRL. This turns the 16 memory locations into a 16 bit shift
register.

The mode of the LUT can't change without reconfiguring the FPGA.
The contents of the LUT can be changed any time if in RAM or SRL
modes.

Regards,
Allan

 

thers no problem with synthesizer nor simulation results
infact simulation results show the output in high impedance
but when i check(using logic probe) that on hardware its not in high
impedance

code is simple
2 inputs ( switches)
1 output (I/O pin)

dout <= din when cnt = '1' else 'Z';




Benjamin Todd wrote:

Post the code that drives the outputs...
And what does the synthesiser say?
B

sachink321@gmail.com> wrote in message
news:1142270059.172147.157840@z34g2000cwc.googlegroups.com...
hi
im using digilab XCR development board which has Xilinx XCR3064
CPLD.
I/O pins in this CPLD are said to be tristate.
but when im trying to use them as tristate
its not working as one?
i mean i want one of the I/O pin to go high impedance but its not?
can any one tell me how can i make I/O pin in CPLD high impedance?

 

[Andy Peters]

sachink321@gmail.com wrote:

thers no problem with synthesizer nor simulation results
infact simulation results show the output in high impedance
but when i check(using logic probe) that on hardware its not in high
impedance

Ummmm, how is the logic probe supposed to know that the pin is
tristated?

-a

 

[maxascent]

I am too trying to get a DDR controller up and running on a Spartan 3 and
have found MIG to be very frustrating. At the moment I am looking at the
DDR controller on opencores and have got it simulating under modelsim. Not
sure how easy it will be to get going on real hardware though. I have
posted a few messages on here regarding DDR and havent really got any
replies so either people are having trouble getting it working or are
keeping quiet

Jon

 

[Eric Smith]

Jim Granville wrote:

You could say core memory still lives on : in FRAM devices =
identical property of magnetic domain storage with destructive read -
only they
are now manufactured on a wafer, with additional process steps to
insert the magnetic domain material, instead of physically wired.

FRAMs are not magnetic. They use the ferroelectric effect, which is
somewhat of a misnomer. They are like core only in that readout is
destructive, but the available FRAM chips handle the rewrite internally.

You're probably thinking about MRAMs, which are magnetic. Freescale
(formerly Motorola) introduced the MR2A16A 4 Mbit MRAM some time back,
but it still doesn't appear to be available through distribution.

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MR2A16A&srch=1

Yes. It worked, but it didn't scale down well, and it was very slow.
Commercial devices were made by Hitachi, Intel, TI, and Rockwell. The
highest density part was the Intel 7114, which was a 4 Mbit part.

There have been some reports lately that MRAM won't scale well, and thus
may also be a dead end. But I think it's too early to write it off.

Many years ago it was claimed that FRAM would be able to achieve comparable
densities to DRAM, but that certainly ahs not happened.

Currently highest density NAND flash parts are 8 Gbit. FRAM and MRAM
thus have only 1/2048 the density of NAND flash, but are fully random
access and have fast read and write times. NAND flash is generally only
suited to secondary storage applications (like disk).

I also see Intel reckons Ovionic (phase change) memory might yet fly...

Samsung and SGS are reportedly working on that as well. Samsung apparently
produced samples of a 64 Mbit chip in 2004.

 

Novice wrote:

I received a design from a vendor, which is designed for Virtex 2 FPGA.
In the design there are four instances of RAMs, which are of DPRAMs of
16bX4096w each. (In fact, there are no WRITE events to these RAMs
throughout simulations.)

In the test bench, a FOR loop reads in some ASCII files and pumps into
RAMs at beginning of each simulation.

Now when I convert this portion into ASIC using library RAMs, how should
I take care of this?

Thank you for your comments.

If it is never written it is rom not ram ....

-Lasse

 

[Evan Lavelle]

On Fri, 10 Mar 2006 20:52:16 GMT, "John_H" <johnhandwork@mail.com>
wrote:

4 - EasyPath is not 'just the same' as the FPGA you were buying
before. When I last looked, it was a device that had failed test.
At a structured ASIC presentation, I railed on the guy that said that Xilinx
was selling bad parts. It's been underscored here before that the parts are
*not* rejects from the main testing that get shoved over to the easypath
line in the same sense as harddrives with bad sectors that didn't need
"those" sectors.

There's certainly a general impression that the parts have failed
test, whatever has been said on c.a.f. I'm pretty sure that I read
this in Xilinx literature a couple of years ago, but I can't find it
now. I may be wrong.

If this is actually the case with Xilinx, then it wouldn't be unusual
(or even "bad"). It used to be fairly common to buy memory devices
which had failed test in only a part of the die, and I've done this
myself. No-one has a problem with this; but, of course, supply will
disappear as yields go up. And I didn't have to pay NREs for them.

The other thing you have to look at is the economics. If these are
good dies, then why are Xilinx selling them cheap? Have a look at my
gross margin argument in my reply to Austin's post.

Evan
--
Riverside
emlat
riverside-machinesdotcodotuk

 

[John Adair]

I would be very careful of using the "locked" signal in any Spartan-3 based
design as it does not always behave in the way that people assume.


John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan-3 Development
Board.
http://www.enterpoint.co.uk


"maxascent" <maxascent@yahoo.co.uk> wrote in message
news:sMmdnUj9krw4IYvZRVn_vA@giganews.com...

If am running a simulation in modelsim an there is a DCM block with a
locked signal. Now because correct me if I am wrong but I would need to
stimulate the locked signal myself because the DCM will not set it as this
is just a simulation and the DCM is a piece of hardware. Hope that makes
sense?

Thanks

Jon

 

[Paul Leventis]

Hi Laura,

Could you please post the product id or name and manufacturer of the
board you are using? There are a lot of Altera FPGA boards floating
around.

Regards,

Paul Leventis
Altera Corp.

 

[John_H]

Evan Lavelle wrote:
<snip>

No, it doesn't. If the silicon cost you *nothing*, then the biggest
discount you could offer would be 35% before eating into your gross
margins. And I can't believe that you do that, or that the silicon
costs you nothing. Oh, and the unit cost advantage of ASICs has
nothing to do with reduced testing.

Gross margins 101:

If the part costs you nothing then your gross margins can stay at 65%
and be - NOTHING!

 

[radarman]

Doh!

I moved the coregen project file to C:\Projects\Cores to avoid the
spaces, but I didn't realize it stored the path in the project file. I
edited the path in the .cgp, and everything is working.

The error should have been a hint...

Oh well, I'm still learning ISE. I've used Altera MaxPlusII or Quartus
my entire career - this is my first Xilinx based design.

Thanks!

 

I've checked the FpgaC version of AES encryption into the FpgaC sf.net
subversion archive under examples/crypto/aes with the Sbox macro
stubbed out waiting for the code Tom suggested. If someone plays with
it, and does the code replacement for the sbox arrays please send me
the changes and i'll include in the example for the next beta release
in April with your name attached.

svn co https://svn.sourceforge.net/svnroot/fpgac/trunk/fpgac fpgac

I got a start on updating FpgaC to handle platform specific technology
mapping so it can use F5/F6/F7 MUXes and do a better job of flattening
the combinatorial tree. Should probably have a chance to finish that
over the weekend, and get it checked in sometime next week. From
looking at the netlists, I suspect that will produce fairly optimal
implementation when done.

Any other suggestions?

Have fun,
John


fpga_toys@yahoo.com wrote:

I did take the Deamon example code for study this morning, and while
not suitable for FPGA implementation because of the all the serialized
looping it was enough to understand the core algorithm pretty quickly.
I re-wrote it into a fully unrolled subset C for FpgaC in a couple
hours that is highly parallel, and pipelined at each round. The Sbox's
are just stubbed out with a define macro, waiting for something
reasonable to place in the macro. It appears that it should run at a
pretty fair clip once someone can provide a set of C statements for the
Sbox implementation you have reference.

it does suffer a bit from a long standing problem we inherited from
TMCC, which is that it doesn't know how to map F5/F6 muxes for
extending 4-LUT equations, and tends to push terms down a little too
quickly forcing a slightly deeper logic tree than optimal. This is also
impacting the PCI core I started as demo code a few weeks ago.

So, I'm off re-writting the FpgaC bottom end code to solve that
problem for good. After the mux fixes, it appears FpgaC can compile the
AES engine to netlist very well, along with the earlier RSA demo code's
barrel shifters.

 

[Allan Herriman]

On 14 Mar 2006 21:57:38 -0800, fpga_toys@yahoo.com wrote:

I've checked the FpgaC version of AES encryption into the FpgaC sf.net
subversion archive under examples/crypto/aes with the Sbox macro
stubbed out waiting for the code Tom suggested. If someone plays with
it, and does the code replacement for the sbox arrays please send me
the changes and i'll include in the example for the next beta release
in April with your name attached.

svn co https://svn.sourceforge.net/svnroot/fpgac/trunk/fpgac fpgac

I got a start on updating FpgaC to handle platform specific technology
mapping so it can use F5/F6/F7 MUXes and do a better job of flattening
the combinatorial tree. Should probably have a chance to finish that
over the weekend, and get it checked in sometime next week. From
looking at the netlists, I suspect that will produce fairly optimal
implementation when done.

Any other suggestions?

How about inferring BRAM for the sboxes? That's what many
implementations do. (I'm assuming the point of the exercise is to
compare the results of an implementation written in C with one written
in a more conventional HDL.)

Regards,
Allan

Have fun,
John


fpga_toys@yahoo.com wrote:
I did take the Deamon example code for study this morning, and while
not suitable for FPGA implementation because of the all the serialized
looping it was enough to understand the core algorithm pretty quickly.
I re-wrote it into a fully unrolled subset C for FpgaC in a couple
hours that is highly parallel, and pipelined at each round. The Sbox's
are just stubbed out with a define macro, waiting for something
reasonable to place in the macro. It appears that it should run at a
pretty fair clip once someone can provide a set of C statements for the
Sbox implementation you have reference.

it does suffer a bit from a long standing problem we inherited from
TMCC, which is that it doesn't know how to map F5/F6 muxes for
extending 4-LUT equations, and tends to push terms down a little too
quickly forcing a slightly deeper logic tree than optimal. This is also
impacting the PCI core I started as demo code a few weeks ago.

So, I'm off re-writting the FpgaC bottom end code to solve that
problem for good. After the mux fixes, it appears FpgaC can compile the
AES engine to netlist very well, along with the earlier RSA demo code's
barrel shifters.

 

[Allan Herriman]

On 14 Mar 2006 19:22:15 -0800, "vssumesh" <vssumesh_asic@yahoo.com>
wrote:

Thanks Allan, found an entry the verilog template provided with Xilinx
ISE. But in that is instantiated as a primitive module. Is there any
way we can instantiate it indirectly using verilog code.

Various RAMs can be instantiated or inferred from your source code.
You should read the XST manual - it will show you how.

Regards,
Allan

 

related topic http://www.fpgajournal.com/articles_2006/20060228_open.htm

 

[Francesco]

maxascent wrote:

I have a DDR design from Xilinx MIG and the lock signal never moves from
'0'. So I have just created my own design with just a DCM and the lock
signal still is '0'. I cant see that I am doing anything particularly
wrong?

Cheers

Jon

Are you resetting the DCM (after at least 16 clocks) ?
is your input clock at least 25 MHz?
did you set the resolution of the simulator at 1ps?

Francesco

 

[Allan Herriman]

On Wed, 15 Mar 2006 08:53:26 +0100, backhus <nix@nirgends.xyz> wrote:

Allan Herriman schrieb:
Hi Eilert,

That's the idea. Your numbers are a little out though. Using a
mature FPGA process (with moderate speed grade) is likley to result in
a clock of about 200MHz if hand placement of the sboxes is used.

AES takes 14 rounds per block.
It might be possible to have feedback around that block without
wasting another clock, but let's assume that it takes 1 extra clock
for the feedback mux, which gives 128 bits of result every 15 clocks.
This results in a throughput of 1.7Gb/s.

A newer FPGA + fastest speed grade + hand placement of some LUTs might
double the numbers. I doubt it could reach a 500MHz clock in an FPGA.

Of course, if one isn't using a feedback mode, many AES engines can be
run in parallel for a vast increase in speed. Alternately, the loops
can be unrolled for the same effect.

I notice that OC192 / STM64 AES encryptors have been available for a
couple of years. I assume these have a single FPGA which produces
approx 20Gb/s of crypto material (10Gb/s encrypt, 10Gb/s decrypt + the
encrypt and decrypt streams are different so they can't share any
hardware).

Regards,
Allan

Hi Allan,
yes, I used some extreme examples to show what's possible with stuff
that is widely available (especially to students) like Spartan2/virtex.
There you rarely get system clocks above 100MHz for larger designs.

For the number of rounds I said "at least". That is 10 for the 128 bit
key, 12(?) for the 192 bit key and 14 for the 256 bit key. Of course I
chose the fastest option to get a higher result in the end.

Customers interested in these speeds seem to care about their data,
and hardware that doesn't support a 256 key probably won't be
commercially viable, so 14 clocks it is.

Whether there's a practical difference in the security for key sizes
of 128, 192 or 256 bits is another matter.

Adding 4 clocks for the feedback mux might have been a little
overestimated when using a single mode. But in the end it was just an
example. No need to make a fuss about some 100 Mbits

The 500 MHz,as mentioned, are just taken from the comercials. But I'm
pretty sure it will be reachable with the Virtex 7 silicon (whenever
that will be).

Well, unrolling the loops was what I meant with "additional rounds and
decrease the number of iterations". Sorry if I didn't said it right.



For the Sonet encryptors you mentioned I found no information about the
modes they use. Can it be possible that they use CTR-Mode?

It's a pretty sure bet they're using CTR mode, since that is the only
secure mode that doesn't use feedback. ECB doesn't use feedback, but
isn't secure. The other modes use feedback.

That one can
use parallel engines indeed. All you need are modulo counters for each
engine and feed them with incremental starting values. Also, for most
modes including CTR you only need encryption rounds. I'm not sure if
that helps any in sharing hardware, but at least you are working with
only one kind of modules (e.g. only Sboxes and no invSboxes etc.) That
eases the design of the chip a lot.

Regards,
Allan

 

For the subversion impaired

http://svn.sourceforge.net/viewcvs.cgi/fpgac/trunk/fpgac/examples/crypto/aes/aes.c?view=markup&rev=49