Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 130925

Article: 130925
Subject: Re: A Challenge for serialized processor design and implementation
From: Paul Keinanen <keinanen@sci.fi>
Date: Sat, 05 Apr 2008 12:40:27 +0300
Links: << >>  << T >>  << A >>
On Sat, 05 Apr 2008 01:28:54 -0800, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>rickman wrote:
>(snip)
>
>> Actually, it is not that you *can* produce all logic from NAND gates,
>> in effect that is how it *is* done.  The basic logic element consists
>> of transistors configured to be a NAND gate, an inverter (a degenerate
>> form of a NAND gate), a NOR gate (a NAND gate with inverted logic) and
>> transmission gates.  So inside of a chip designed at the gate level,
>> there really is no distinction between NAND and NOR gates and there
>> are no OR and AND gates.
>
>I believe that is pretty much true for TTL, and I believe
>also for ECL, PMOS and NMOS, but not for CMOS.

ECL is OR/NOR, since it is basically a differential pair (with
multiple transistors in parallel with the left transistor for multiple
input gates) and the output can be taken (using an emitter follower)
from either collector resistor of the differential pair to get OR or
NOR functionality. If the output is taken from both sides, there are
simultaneous OR and NOR outputs.

In ECL the EXOR gate can be implemented by replacing the differential
pair collector resistors with two additional differential pairs as in
a Gilbert cell mixer (MC1496 style).

Paul


Article: 130926
Subject: Re: PLA datasheet - PLS161
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sat, 05 Apr 2008 22:22:59 +1200
Links: << >>  << T >>  << A >>
Joseph wrote:

> Hi all,
> 
> I am looking for the datasheet of the PLS161 which was a PLA. My
> interest in it is purely academic. I am teaching a high level digital
> electronics course and would like my students to see a datasheet of a
> PLA before progressing to CPLD and FPGA's
> 
> I would be very grateful if someone could give me the datasheet of
> this device or a similar PLA.
> 
> Many thanks

Try the PLC42VA12 ?
Quite clear drawings, and a descendent of the PLS161

http://www.nxp.com/acrobat_download/datasheets/PC42VA12.pdf

and this simpler sibling ?
http://www.nxp.com/acrobat_download/datasheets/PLC18V8Z.pdf

Those two, should give a reasonable stepping stone sequence.

The CoolRunner still has aspects of PLA (able to share product terms)
but the data sheets are not as well drawn.

-jg


Article: 130927
Subject: Re: PLA datasheet - PLS161
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sat, 05 Apr 2008 22:35:22 +1200
Links: << >>  << T >>  << A >>
Jim Granville wrote:

> Joseph wrote:
> 
>> Hi all,
>>
>> I am looking for the datasheet of the PLS161 which was a PLA. My
>> interest in it is purely academic. I am teaching a high level digital
>> electronics course and would like my students to see a datasheet of a
>> PLA before progressing to CPLD and FPGA's
>>
>> I would be very grateful if someone could give me the datasheet of
>> this device or a similar PLA.
>>
>> Many thanks
> 
> 
> Try the PLC42VA12 ?
> Quite clear drawings, and a descendent of the PLS161
> 
> http://www.nxp.com/acrobat_download/datasheets/PC42VA12.pdf
> 
> and this simpler sibling ?
> http://www.nxp.com/acrobat_download/datasheets/PLC18V8Z.pdf
> 
> Those two, should give a reasonable stepping stone sequence.
> 
> The CoolRunner still has aspects of PLA (able to share product terms)
> but the data sheets are not as well drawn.

I'll add a bit more:

For current production devices, look at Atmel who have SPLD and CPLD.

http://www.atmel.com/dyn/products/datasheets.asp?family_id=653
http://www.atmel.com/dyn/products/other_docs.asp?family_id=653

A good CPLD Macrocell drawing is here:

http://www.atmel.com/dyn/resources/prod_documents/doc3659.pdf

Atmel tool flows are small and nimble, and can fit on a USB Flash Drive.

So, if you wanted, students could actually compile something, or
you could set some homework to have them change some aspect of
an example design.

The FIT report files are very readable, so they hand those in, and you
mark that.

-jg




Article: 130928
Subject: Re: Antii, can you give us an update?
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sat, 05 Apr 2008 13:41:42 +0100
Links: << >>  << T >>  << A >>
On Fri, 4 Apr 2008 23:56:37 -0700 (PDT), Antti <Antti.Lukats@googlemail.com>
wrote:

>On 2 Apr., 18:22, Antti <Antti.Luk...@googlemail.com> wrote:
>> On 1 Apr., 14:31, "Nial Stewart"
>>
>> <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
>> > I've read all the posts here but have lost track of how you're
>> > getting on.
>>
>> > Can you post an update and describe what the problem turned out
>> > to be?
>>
>> > Nial.
>>
>> Quote from Actel website: "In March 2008, it was discovered that a
>> potential advanced optimization could cause a logic gating of a global
>> signal. 

>> This is fixed in Libero 8.3 released march 31 2008

>updating to 8.3 did not fix the problems, but I am getting closer
>status:

>in desing exist async strobes A1, A2 (A1 byte rd/wr strobe, A2 spi
>slave from ext mcu)
>
>loadable LFSR in A1 domain
>2:1 MUX for the selecting the load value
>1 input of mux = const, loaded at powerup
>2 input of mux connected to 24 bit shift register in A2 domain
>
>LFSR is loaded with constant at powerup, and loaded
>with current value in spi shift register ONCE, after
>that load the load enable signal is FULLY DISABLED

>but when the there is data shifted in into the spi shift
>register connected to the input mux of the LFSR load input
>then some sequences of data make the LFSR content corrupt
>
>these sequences are REPEATABLE, that is not random!

As I understand it, the SPI register and the LFSR register are on different
clock domains; with purely combinational logic (the mux, and the Load Enable)
between them.

In Xilinx, as I understand it, if a 4-Lut transitions between one
Load_Enable=FALSE state, and another Load_Enable=FALSE state, it is guaranteed
not to glitch via a Load_Enable=True state. 

I don't know Actel at all - is the same guarantee true there?

If not, I believe you need an intermediate register (just a simple pipeline
register) clocked in the LFSR clock domain, to hold a copy of the SPI shift
register. (This copy is subject to metastability, but with a tiny window of
opportunity). Whereas now, you are exposed to the possibility of glitches
derived from the SPI clock, and latched on the LFSR clock.

> That is the LFSR gets corrupted at certaing
>values being visible on the load input via mux

... or certain TRANSITIONS being visible on the load input?

IF the mux and the load enable logic are rolled into the same combinational
cloud, AND 0->0 via glitch 1 is possible, then you are exposed to invalid values
during a settling time window after the ... wrong clock.

>I already have forced the LFSR enable and mux select
>to global clocks

I'm not sure that helps (it may reduce errors by an order of magnitude or more,
but it leaves you open to the possibility above)

>of course the SPI clock and LFSR clocks are global
>clocks as well
... good...

just a guess but on the information given, it looks plausible to me.

- Brian


Article: 130929
Subject: Re: Antii, can you give us an update?
From: Antti <Antti.Lukats@googlemail.com>
Date: Sat, 5 Apr 2008 10:37:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 5 Apr., 14:41, Brian Drummond <brian_drumm...@btconnect.com> wrote:
> On Fri, 4 Apr 2008 23:56:37 -0700 (PDT), Antti <Antti.Luk...@googlemail.com>
> wrote:
>
>
>
> >On 2 Apr., 18:22, Antti <Antti.Luk...@googlemail.com> wrote:
> >> On 1 Apr., 14:31, "Nial Stewart"
>
> >> <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> >> > I've read all the posts here but have lost track of how you're
> >> > getting on.
>
> >> > Can you post an update and describe what the problem turned out
> >> > to be?
>
> >> > Nial.
>
> >> Quote from Actel website: "In March 2008, it was discovered that a
> >> potential advanced optimization could cause a logic gating of a global
> >> signal.
> >> This is fixed in Libero 8.3 released march 31 2008
> >updating to 8.3 did not fix the problems, but I am getting closer
> >status:
> >in desing exist async strobes A1, A2 (A1 byte rd/wr strobe, A2 spi
> >slave from ext mcu)
>
> >loadable LFSR in A1 domain
> >2:1 MUX for the selecting the load value
> >1 input of mux = const, loaded at powerup
> >2 input of mux connected to 24 bit shift register in A2 domain
>
> >LFSR is loaded with constant at powerup, and loaded
> >with current value in spi shift register ONCE, after
> >that load the load enable signal is FULLY DISABLED
> >but when the there is data shifted in into the spi shift
> >register connected to the input mux of the LFSR load input
> >then some sequences of data make the LFSR content corrupt
>
> >these sequences are REPEATABLE, that is not random!
>
> As I understand it, the SPI register and the LFSR register are on different
> clock domains; with purely combinational logic (the mux, and the Load Enable)
> between them.
>
> In Xilinx, as I understand it, if a 4-Lut transitions between one
> Load_Enable=FALSE state, and another Load_Enable=FALSE state, it is guaranteed
> not to glitch via a Load_Enable=True state.
>
> I don't know Actel at all - is the same guarantee true there?
>
> If not, I believe you need an intermediate register (just a simple pipeline
> register) clocked in the LFSR clock domain, to hold a copy of the SPI shift
> register. (This copy is subject to metastability, but with a tiny window of
> opportunity). Whereas now, you are exposed to the possibility of glitches
> derived from the SPI clock, and latched on the LFSR clock.
>
> > That is the LFSR gets corrupted at certaing
> >values being visible on the load input via mux
>
> ... or certain TRANSITIONS being visible on the load input?
>
> IF the mux and the load enable logic are rolled into the same combinational
> cloud, AND 0->0 via glitch 1 is possible, then you are exposed to invalid values
> during a settling time window after the ... wrong clock.
>
> >I already have forced the LFSR enable and mux select
> >to global clocks
>
> I'm not sure that helps (it may reduce errors by an order of magnitude or more,
> but it leaves you open to the possibility above)
>
> >of course the SPI clock and LFSR clocks are global
> >clocks as well
>
> ... good...
>
> just a guess but on the information given, it looks plausible to me.
>
> - Brian

Hi Brian,

the story goes even more fascinating (or frustrating)...

first about Actel - their Logic Cell is NOT LUT based, so the
LUT input transition glitches can not happen (no LUT!) but
actel cell has NO DEDICATED flip-flop, and flip flops are
configured out of logic, and have severe restrictions on
configuration and routing, FF with enable and clear are
made out 2 cells if CLR signal is not driven by global clock
sometimes 4 cells are used to make 1 single flip flop.

the use of global clocks in actel, sometimes its not
"order of magnitude" difference but simple OK vs FAIL 100% issue

case: 64 bit shift register (no enable just shift), clocked with CLEAN
clock at 4mhz

work 100% when FPGA is almost empty (no matter what signal drivers
shift reg clock)
fails 100% when FPGA is >90% and shift clock is ruouted with local
connects

PROVEN. this is also explanaibale, and actel has special appnote for
this (clock skew handling)
==
now to my clocking issue

after taking a break I tried to eliminate things from the problem, so
I stopped shifting data
into the SPI shift register. this however made no difference, and when
i looked again
it was also explanaible as my test counter value was decoded in
external AR MCU
but the bytes holding the counter value did never get back into the
FPGA!

so to summarize again:

1) ARM9 SW has counter, that is used to generate 8 byte encrypted
token
2) those 8 bytes are going into FPGA over A1 parallel interface they
are written into dual port BRAM
3) those 8 bytes are read by AVR over SPI interface
4) AVR decodes those bytes, it also decodes the counter from step 1,
NO ERROR ever here
5) AVR writes 3 bytes to FPGA SPI shift register
6) AVR strobes to load LFSR, and set one time flag that prevents
further LFSR loads
7) ARM9 sends packets in loop (encrypted counter)

now, the counter value NEVER exist inside FPGA
the data passed via FPGA is not decoded there
the data passed via FPGA is not used by the logic responsible for the
load/enable of the LFSR

still at some certain counter value, the LFSR does get corrupted!!
those values are repeatable, they are not random, that is each time
the ARM9 counter is
restarted then at exactly same counter values the LFSR is corrupted.
those values are however different for different PCB+bitstream
combinations

8) AVR puts FPGA into main mode
9) ARM9 sends any packets any number of hours LFSR corruption no
longer happens! no single errror seen

errors happen at [7] at const numbers of counter
error NEVER happen at [9] while streaming random data for hours..

so there is no different transitions on the load input of the LFSR at
all, still there is repeatable dependancy
on the data stream that only passes through FPGA

eeee... [8] what happens there?

well after main mode the AVR no longer collects data from FPGA and no
longer decrypts it.
but that should no have any influence as the decrypt result wasnt
passing into the FPGA anyway.

there is one more difference,
after [8] the LFSR is enabled for 8 clocks lonfer for each packet from
A1 interface

but the LFSR enable/load signals do not share any logic with any of
the data lines !!

Ok, when found out that the counter data is not passing into the load
input at all, i did take a walk
and coffee break, and did write a list of options that can be tested,
list with 6 items, so will work
them out one by one

my bet is that I need add delay on the LFSR enable signal, there is no
explanation why it should
be used as it is already a FF in the same clock domain as the LFSR
clock, but all other items
on my list of possible problems are even less likely (or harder to
test)

Antti

Article: 130930
Subject: Re: synplify pro generates negative slack
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 05 Apr 2008 10:42:18 -0700
Links: << >>  << T >>  << A >>
ni wrote:

> I have recently started(1 week) using Synplify pro. For two years in
> my fpga designs I never used synplify pro. For most of the generic
> component I used to use core generator and then instantiate those
> component in my vhdl code.

Next time post to comp.lang.vhdl.

Start with the Synplify pro vhdl synthesis guide.
Most of the core generator blocks can be replaced by a few
lines of vhdl code, but there is a learning period.

Here's some brand A examples :
http://www.altera.com/support/examples/vhdl/vhdl.html

Here's some brand X examples :
http://www.xilinx.com/support/documentation/hdl_and_synthesis.htm

Here are my examples.
http://home.comcast.net/~mike_treseler/

Good luck.

       -- Mike Treseler

Article: 130931
Subject: Re: Virtex-5 FXT coming soon?
From: Simon <wlpstxzhd@gmail.com>
Date: Sat, 5 Apr 2008 11:12:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 23, 4:01 pm, pmull...@yahoo.com wrote:
> On Mar 3, 10:22 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote:
>
> > "Antti" <Antti.Luk...@googlemail.com> wrote in message
>
> >news:ee42d07c-3062-489e-93b1-d9afa01fbbac@y77g2000hsy.googlegroups.com...
>
> > > On 3 Mrz., 17:15, Kolja Sulimma <ksuli...@googlemail.com> wrote:
> > >> On 3 Mrz., 11:20, Antti <Antti.Luk...@googlemail.com> wrote:
>
> > >> > but as the V5FX has been delaying so long, I have almost lost interest
> > >> > to follow up how much longer it is delaying in reality...
>
> > >> > The Spartan-4 is much more interesting,
>
> > >> Well, we are desperately waiting for the V5 MGTs.
> > >> Actually we need a solution for 10gbps soon as XAUI is going to be
> > >> replaced
> > >> by SFP+ really soon. We can't place external 10G serdes on 12 ports.
>
> > >> Kolja Sulimma
>
> > > well EVERY new xilinx family since V2ProX is DOWNGRADING the speed of
> > > MGTs
> > > V4 less than V2
> > > V5 less than V4
>
> > > so you may need wait V6 :(
>
> > > Antti
>
> > V6? Don't hold your breath.
>
> > A reliable source tells me that the 10Gbps serdes will be fully functional
> > in V12 Pro (they're skipping V13 for obvious reasons).
>
> > Bob
>
> I would check with Altera on Serdes as they have done it right and
> have been up to 6 Gbps for years.

As shown on the homepage of Xilinx, the new Virtex5 FXT is out now.
Does anybody know whether there is development board featured with
Virtex5 FXT available? Is that ML507, if so where is the info or data
sheet for this board?

Simon

Article: 130932
Subject: Re: Protecting design from being downloaded on other (similar) FPGA
From: Bob Smith <usenet@linuxtoys.org>
Date: Sat, 05 Apr 2008 11:30:27 -0700
Links: << >>  << T >>  << A >>
maverick wrote:
> I need to know how can I prohibit a configuration file from being
> downloaded on a similar FPGA device.

How about adding an XC2C32 CPLD to the board and routing all
of the bitstream data through it?  Since it is flash based
you could put a unique key in each one at board build time
and use the key to encode/decode the bitstream.  This does
not give good protection since a digital scope on the DIN
and CCLK pins would give the unencrypted bitstream but it
might be enough for your needs.  The XC2C32 is a little over
a buck in 100 quantity at Digi-Key.

HTH
Bob Smith

Article: 130933
Subject: Re: Protecting design from being downloaded on other (similar) FPGA
From: Antti <Antti.Lukats@googlemail.com>
Date: Sat, 5 Apr 2008 12:28:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 5 Apr., 20:30, Bob Smith <use...@linuxtoys.org> wrote:
> maverick wrote:
> > I need to know how can I prohibit a configuration file from being
> > downloaded on a similar FPGA device.
>
> How about adding an XC2C32 CPLD to the board and routing all
> of the bitstream data through it?  Since it is flash based
> you could put a unique key in each one at board build time
> and use the key to encode/decode the bitstream.  This does
> not give good protection since a digital scope on the DIN
> and CCLK pins would give the unencrypted bitstream but it
> might be enough for your needs.  The XC2C32 is a little over
> a buck in 100 quantity at Digi-Key.
>
> HTH
> Bob Smith

the OP wants COTS board to be used
1) with no mods to the board
2) with no additions to the board

so adding anything isnt an option

Antti




Article: 130934
Subject: Re: A Challenge for serialized processor design and implementation
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sun, 06 Apr 2008 11:29:17 +1200
Links: << >>  << T >>  << A >>
referringto@googlemail.com wrote:
> It was the next challenge after maxing out on CPLDs (see
> http://www.opencores.org/projects.cgi/web/mcpu/overview).

This looked nifty, so I've downloaded this and had a quick try :

Could not fit into a 9536, or 9536XL - just too many product terms.
(with default settings), so it bumped to the 72MC devices, just over 50% 
full.

Auto-Fitted in XC2C64, but generated 34MC's. (SIZE optimised), but PT 
looks OK for a smaller device.
However, I did see it generated a number of intermediate Macrocells....

Hmmm... so I switched to Speed, thinking that might avoid some 
intermediate MCs - and, strangely, Speed optimised now FITS 
XC2C32A,where SIZE failed :)

Only just, but as your target was 32MC's this counts as a PASS!

[ Need to find something for that extra MC and 3PTs to do :)
- maybe a Debug/Trace LED ?, could select 1 of 3 probe points ? ]

RESOURCES SUMMARY
Design Name   			cpu8bit2
Device				XC2C32-3-PC44
Macrocells Used 		31/32  (97%)
Pterms Used 			109/112(98%)
Registers Used 			24/32  (75%)
Pins Used 			18/33  (55%)
Function Block Inputs Used  	70/80  (88%)

You could add this newer device to your 32 MCell supported list.
( and I'd suggest appending the full FIT cpu8bit2.rpt file to the PDFs )

-jg


Article: 130935
Subject: Re: Virtex-5 FXT coming soon?
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sat, 5 Apr 2008 17:05:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 5, 11:12=A0am, Simon <wlpstx...@gmail.com> wrote:
> On Mar 23, 4:01 pm, pmull...@yahoo.com wrote:
>
>
>
> > On Mar 3, 10:22 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote:
>
> > > "Antti" <Antti.Luk...@googlemail.com> wrote in message
>
> > >news:ee42d07c-3062-489e-93b1-d9afa01fbbac@y77g2000hsy.googlegroups.com.=
..
>
> > > > On 3 Mrz., 17:15, Kolja Sulimma <ksuli...@googlemail.com> wrote:
> > > >> On 3 Mrz., 11:20, Antti <Antti.Luk...@googlemail.com> wrote:
>
> > > >> > but as the V5FX has been delaying so long, I have almost lost int=
erest
> > > >> > to follow up how much longer it is delaying in reality...
>
> > > >> > The Spartan-4 is much more interesting,
>
> > > >> Well, we are desperately waiting for the V5 MGTs.
> > > >> Actually we need a solution for 10gbps soon as XAUI is going to be
> > > >> replaced
> > > >> by SFP+ really soon. We can't place external 10G serdes on 12 ports=
.
>
> > > >> Kolja Sulimma
>
> > > > well EVERY new xilinx family since V2ProX is DOWNGRADING the speed o=
f
> > > > MGTs
> > > > V4 less than V2
> > > > V5 less than V4
>
> > > > so you may need wait V6 :(
>
> > > > Antti
>
> > > V6? Don't hold your breath.
>
> > > A reliable source tells me that the 10Gbps serdes will be fully functi=
onal
> > > in V12 Pro (they're skipping V13 for obvious reasons).
>
> > > Bob
>
> > I would check with Altera on Serdes as they have done it right and
> > have been up to 6 Gbps for years.
>
> As shown on the homepage of Xilinx, the new Virtex5 FXT is out now.
> Does anybody know whether there is development board featured with
> Virtex5 FXT available? Is that ML507, if so where is the info or data
> sheet for this board?
>
> Simon

To the best of my knowledge, the ML507 board is identical in layout
and appearance with the ML505 board, since the 'LXT and 'FXT chips are
pin-compatible.
Let's see on Monday at work...
Peter Alfke

Article: 130936
Subject: Re: Protecting design from being downloaded on other (similar) FPGA
From: Alan Nishioka <alan@nishioka.com>
Date: Sat, 5 Apr 2008 17:13:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
> I am trying to prohibit generation of multiple copies of the
> same system. For example, assume that I have developed a system which
> comprises of a PC and a PCI based FPGA board which is mounted on the
> PCI slot of the same PC. The PCI based FPGA board is commercially
> availble from a vendor. The host application that runs on the PC
> programs the FPGA on application startup.

Every PCI slot on a PC has a unique bus/slot number that you could use
to selectively download fpga code.  Unfortunately, the mapping between
these numbers and the physical slot is not always obvious.

If you have two identical cards and no way to tell them apart, you are
going to need some sort of user intervention to select which card to
program.  The mental telepathy option is usually disabled in the BIOS.

Actually, if the cards are truly identical, then it shouldn't matter
which one you program.  Just program the first one you find and assume
there aren't any others.

Alan Nishioka

Article: 130937
Subject: problem with synthesis of a state machine
From: Fei Liu <fei.liu@gmail.com>
Date: Sat, 5 Apr 2008 18:17:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
The following code runs well in simulation mode but synthesis fails.
Please let me know how I can get this synthesized, thanks!

Fei
`timescale 1ns / 1ps
module blink_led(clk, d, led);
    input clk;
    input d;
    output wire led;

parameter blink_freq = 2;
reg [blink_freq:0] count = 0;
reg [1:0] state = 0;
reg [1:0] next_state = 0;
assign led = !count[blink_freq];

always @(posedge clk)
begin
	state <= next_state;
	if(state == 2'b01)
	begin
		count <= count + 1;
		if(count[blink_freq])
			next_state <= 2'b10;
		else
			next_state <= 2'b01;
	end
end

always @(state or d) begin
	case(state)
	2'b00:
		if(d)
			next_state <= 2'b01;
		else
			next_state <= 2'b00;
	2'b01:
		begin
			count <= count + 1;
			if(count[blink_freq])
				next_state <= 2'b10;
			else
				next_state <= 2'b01;
		end
	2'b10:
		begin
			count <= 0;
			next_state <= 2'b00;
		end
	default:
		begin
			next_state <= state;
		end
	endcase
end

endmodule

module stimuli;

reg clk=0;
reg d=0;
wire led;

blink_led bl(.clk (clk), .d(d), .led(led));

initial
	forever #20 clk = ~clk;

initial begin
	#80 d = 1;
	#40 d = 0;
	#140 d = 1;
	forever #40 d = ~d;
end

endmodule

ERROR:Xst:528 - Multi-source in Unit <blink_led> on signal
<Madd_count_addsub0000_cy<0>>
Sources are:
   Output signal of LD instance <count_ren_0>
   Output signal of FDE instance <count_0>

ERROR:Xst:528 - Multi-source in Unit <blink_led> on signal
<Madd_count_addsub00002>
Sources are:
   Output signal of LD instance <count_ren_1>
   Output signal of FDE instance <count_1>

ERROR:Xst:528 - Multi-source in Unit <blink_led> on signal
<Madd_count_addsub00004>
Sources are:
   Output signal of LD instance <count_ren_2>
   Output signal of FDE instance <count_2>
CPU : 6.41 / 6.66 s | Elapsed : 7.00 / 7.00 s

-->

Total memory usage is 154044 kilobytes

Number of errors   :    3 (   0 filtered)
Number of warnings :    2 (   0 filtered)
Number of infos    :    1 (   0 filtered)


Process "Synthesize" failed

Article: 130938
Subject: Re: problem with synthesis of a state machine
From: Fei Liu <fei.liu@gmail.com>
Date: Sat, 5 Apr 2008 19:39:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 5, 9:17 pm, Fei Liu <fei....@gmail.com> wrote:
> The following code runs well in simulation mode but synthesis fails.
> Please let me know how I can get this synthesized, thanks!
>
> Fei

I've managed to code this to get synthesis done but I don't understand
why next_state can be assigned in both always blocks but count cannot?
The only difference is count update depends on count itself...

`timescale 1ns / 1ps

module blink_led(clk, d, led);
    input clk;
    input d;
    output wire led;

parameter blink_freq = 2;
reg [blink_freq:0] count = 0;
reg [1:0] state = 0;
reg [1:0] next_state = 0;
assign led = !count[blink_freq];

always @(posedge clk)
begin
	state <= next_state;
	case(state)
	2'b01:
		begin
			count <= count + 1;
			if(count[blink_freq])
				next_state <= 2'b10;
			else
				next_state <= 2'b01;
		end
	2'b10:
		count <= 0;
	endcase
end

always @(state or d or count) begin
	case(state)
	2'b00:
		if(d)
			next_state <= 2'b01;
		else
			next_state <= 2'b00;
	2'b01:
		begin
			if(count[blink_freq])
				next_state <= 2'b10;
			else
				next_state <= 2'b01;
		end
	2'b10:
		begin
			next_state <= 2'b00;
		end
	default:
		begin
			next_state <= state;
		end
	endcase
end

endmodule

module stimuli;

reg clk=0;
reg d=0;
wire led;

blink_led bl(.clk (clk), .d(d), .led(led));

initial
	forever #20 clk = ~clk;

initial begin
	#80 d = 1;
	#40 d = 0;
	#140 d = 1;
	forever #40 d = ~d;
end

endmodule

Article: 130939
Subject: Re: problem with synthesis of a state machine
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 05 Apr 2008 18:52:20 -0800
Links: << >>  << T >>  << A >>
Fei Liu wrote:

> The following code runs well in simulation mode but synthesis fails.
> Please let me know how I can get this synthesized, thanks!

(snip)

> blink_led bl(.clk (clk), .d(d), .led(led));
> 
> initial
> 	forever #20 clk = ~clk;
> 
> initial begin
> 	#80 d = 1;
> 	#40 d = 0;
> 	#140 d = 1;
> 	forever #40 d = ~d;
> end

It is usual not to be able to synthesize the above logic.
Pretty much anything with a numeric delay won't synthesize.

> ERROR:Xst:528 - Multi-source in Unit <blink_led> on signal
> <Madd_count_addsub0000_cy<0>>
> Sources are:
>    Output signal of LD instance <count_ren_0>
>    Output signal of FDE instance <count_0>

This means there are two outputs connected together.

You can't do that in real logic as the output drivers
will fight each other, often with large currents flowing.

Without going all the way through the logic, I believe
it is count that has more than one source.

-- glen


Article: 130940
Subject: Re: problem with synthesis of a state machine
From: Muzaffer Kal <kal@dspia.com>
Date: Sat, 05 Apr 2008 21:01:04 -0700
Links: << >>  << T >>  << A >>
On Sat, 5 Apr 2008 18:17:24 -0700 (PDT), Fei Liu <fei.liu@gmail.com>
wrote:

>The following code runs well in simulation mode but synthesis fails.
>Please let me know how I can get this synthesized, thanks!

I'm assuming you're not trying to synthesize your test-bench ie module
stimuli. You can only synthesize blink_led and if you want to exercise
it after synthesis, you can use the gate level version under your
test-bench or implement in an fpga and drive the pins on the board.

As to synthesizing the blink_led module, you need to make sure that
any signal is driven from only one always block. Put all next_state
and count assignments to the second (combinational) block. You can add
another set of wires for something like count_d and assign it in the
second block (ie count_d = count + 1; etc) and add count <= count_d;
to your first (sequential) block unconditionally.
Your code should look as follows: 

always @(posedge clk)
begin
	state <= next_state;
	count <= count_d;
end

always @(*)
begin
	case (state)
	...
		next_state = foo;
		count_d = count + 1;
	...		
end

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

Article: 130941
Subject: Re: problem with synthesis of a state machine
From: Fei Liu <fei.liu@gmail.com>
Date: Sat, 5 Apr 2008 21:35:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 6, 12:01 am, Muzaffer Kal <k...@dspia.com> wrote:
> On Sat, 5 Apr 2008 18:17:24 -0700 (PDT), Fei Liu <fei....@gmail.com>
> wrote:
>
> >The following code runs well in simulation mode but synthesis fails.
> >Please let me know how I can get this synthesized, thanks!
>
> I'm assuming you're not trying to synthesize your test-bench ie module
> stimuli. You can only synthesize blink_led and if you want to exercise
> it after synthesis, you can use the gate level version under your
> test-bench or implement in an fpga and drive the pins on the board.
>
> As to synthesizing the blink_led module, you need to make sure that
> any signal is driven from only one always block. Put all next_state
> and count assignments to the second (combinational) block. You can add
> another set of wires for something like count_d and assign it in the
> second block (ie count_d = count + 1; etc) and add count <= count_d;
> to your first (sequential) block unconditionally.
> Your code should look as follows:
>
> always @(posedge clk)
> begin
>         state <= next_state;
>         count <= count_d;
> end
>
> always @(*)
> begin
>         case (state)
>         ...
>                 next_state = foo;
>                 count_d = count + 1;
>         ...
> end
>
> Muzaffer Kal
> ASIC/FPGA Design Services
> DSPIA INC.http://www.dspia.com

Thanks, I think my second iteration does exactly what you described
here. I do have one last doubt about timing. In my synthesizable
version, when I run the test bench, the value of state always lags
behind next_state for 1 or half clock period. My understanding is that
since they are in separate always blocks, the simulation is free to do
this assignment with a delay. Is there a deeper reason why state value
always lag behind next_state for 1 clk?

clk period = 40

                   0 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                  20 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                  40 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                  60 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                  80 clk = 0, d = 1, led = 0, state = 00, next_state =
01 <---
                 100 clk = 1, d = 1, led = 1, state = 01, next_state =
01 <---
                 120 clk = 0, d = 0, led = 1, state = 01, next_state =
01
                 140 clk = 1, d = 0, led = 1, state = 01, next_state =
01
                 160 clk = 0, d = 0, led = 1, state = 01, next_state =
01
                 180 clk = 1, d = 0, led = 1, state = 01, next_state =
01
                 200 clk = 0, d = 0, led = 1, state = 01, next_state =
01
                 220 clk = 1, d = 0, led = 1, state = 01, next_state =
01
                 240 clk = 0, d = 0, led = 1, state = 01, next_state =
01 <---
                 260 clk = 1, d = 1, led = 1, state = 01, next_state =
10 <---
                 280 clk = 0, d = 1, led = 1, state = 01, next_state =
10
                 300 clk = 1, d = 0, led = 0, state = 10, next_state =
00
                 320 clk = 0, d = 0, led = 0, state = 10, next_state =
00
                 340 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                 360 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                 380 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                 400 clk = 0, d = 1, led = 0, state = 00, next_state =
01
                 420 clk = 1, d = 1, led = 1, state = 01, next_state =
01
                 440 clk = 0, d = 0, led = 1, state = 01, next_state =
01
                 460 clk = 1, d = 0, led = 1, state = 01, next_state =
01
                 480 clk = 0, d = 0, led = 1, state = 01, next_state =
01
                 500 clk = 1, d = 0, led = 1, state = 01, next_state =
01
                 520 clk = 0, d = 0, led = 1, state = 01, next_state =
01
                 540 clk = 1, d = 0, led = 1, state = 01, next_state =
01
                 560 clk = 0, d = 0, led = 1, state = 01, next_state =
01
                 580 clk = 1, d = 0, led = 1, state = 01, next_state =
10 <----
                 600 clk = 0, d = 0, led = 1, state = 01, next_state =
10
                 620 clk = 1, d = 0, led = 0, state = 10, next_state =
00 <----
                 640 clk = 0, d = 0, led = 0, state = 10, next_state =
00
                 660 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                 680 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                 700 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                 720 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                 740 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                 760 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                 780 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                 800 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                 820 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                 840 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                 860 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                 880 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                 900 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                 920 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                 940 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                 960 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                 980 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                1000 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                1020 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                1040 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                1060 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                1080 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                1100 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                1120 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                1140 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                1160 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                1180 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                1200 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                1220 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                1240 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                1260 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                1280 clk = 0, d = 0, led = 0, state = 00, next_state =
00
                1300 clk = 1, d = 0, led = 0, state = 00, next_state =
00
                1320 clk = 0, d = 0, led = 0, state = 00, next_state =
00

Also of course I wasn't trying to synthesize the test bench code...

Thanks,

Article: 130942
Subject: Re: problem with synthesis of a state machine
From: Muzaffer Kal <kal@dspia.com>
Date: Sat, 05 Apr 2008 22:20:35 -0700
Links: << >>  << T >>  << A >>
On Sat, 5 Apr 2008 21:35:52 -0700 (PDT), Fei Liu <fei.liu@gmail.com>
wrote:

>Thanks, I think my second iteration does exactly what you described
>here. I do have one last doubt about timing. In my synthesizable
>version, when I run the test bench, the value of state always lags
>behind next_state for 1 or half clock period. My understanding is that
>since they are in separate always blocks, the simulation is free to do
>this assignment with a delay. Is there a deeper reason why state value
>always lag behind next_state for 1 clk?

Actually there is. This is exactly how sequential logic is supposed to
work. At every positive edge of the clock the registers store the
value at their input and their output changes. This is accomplished by
the first always block. Then the combinational always block takes the
register outputs and calculates the next cycle's values which are not
noticed by the registers till the next clock.
With actual logic delays, the calculation of the next state can take
almost all the period of a single cycle so correct data may not arrive
at the input of the registers till almost the next clock cycle has
arrived. If clock arrives after the next state is calculated it is
said that the circuit "meets timing". 

Article: 130943
Subject: Re: Antii, can you give us an update?
From: Antti <Antti.Lukats@googlemail.com>
Date: Sun, 6 Apr 2008 04:53:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 5 Apr., 19:37, Antti <Antti.Luk...@googlemail.com> wrote:
> On 5 Apr., 14:41, Brian Drummond <brian_drumm...@btconnect.com> wrote:
>
>
>
> > On Fri, 4 Apr 2008 23:56:37 -0700 (PDT), Antti <Antti.Luk...@googlemail.com>
> > wrote:
>
> > >On 2 Apr., 18:22, Antti <Antti.Luk...@googlemail.com> wrote:
> > >> On 1 Apr., 14:31, "Nial Stewart"
>
> > >> <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > >> > I've read all the posts here but have lost track of how you're
> > >> > getting on.
>
> > >> > Can you post an update and describe what the problem turned out
> > >> > to be?
>
> > >> > Nial.
>
> > >> Quote from Actel website: "In March 2008, it was discovered that a
> > >> potential advanced optimization could cause a logic gating of a global
> > >> signal.
> > >> This is fixed in Libero 8.3 released march 31 2008
> > >updating to 8.3 did not fix the problems, but I am getting closer
> > >status:
> > >in desing exist async strobes A1, A2 (A1 byte rd/wr strobe, A2 spi
> > >slave from ext mcu)
>
> > >loadable LFSR in A1 domain
> > >2:1 MUX for the selecting the load value
> > >1 input of mux = const, loaded at powerup
> > >2 input of mux connected to 24 bit shift register in A2 domain
>
> > >LFSR is loaded with constant at powerup, and loaded
> > >with current value in spi shift register ONCE, after
> > >that load the load enable signal is FULLY DISABLED
> > >but when the there is data shifted in into the spi shift
> > >register connected to the input mux of the LFSR load input
> > >then some sequences of data make the LFSR content corrupt
>
> > >these sequences are REPEATABLE, that is not random!
>
> > As I understand it, the SPI register and the LFSR register are on different
> > clock domains; with purely combinational logic (the mux, and the Load Enable)
> > between them.
>
> > In Xilinx, as I understand it, if a 4-Lut transitions between one
> > Load_Enable=FALSE state, and another Load_Enable=FALSE state, it is guaranteed
> > not to glitch via a Load_Enable=True state.
>
> > I don't know Actel at all - is the same guarantee true there?
>
> > If not, I believe you need an intermediate register (just a simple pipeline
> > register) clocked in the LFSR clock domain, to hold a copy of the SPI shift
> > register. (This copy is subject to metastability, but with a tiny window of
> > opportunity). Whereas now, you are exposed to the possibility of glitches
> > derived from the SPI clock, and latched on the LFSR clock.
>
> > > That is the LFSR gets corrupted at certaing
> > >values being visible on the load input via mux
>
> > ... or certain TRANSITIONS being visible on the load input?
>
> > IF the mux and the load enable logic are rolled into the same combinational
> > cloud, AND 0->0 via glitch 1 is possible, then you are exposed to invalid values
> > during a settling time window after the ... wrong clock.
>
> > >I already have forced the LFSR enable and mux select
> > >to global clocks
>
> > I'm not sure that helps (it may reduce errors by an order of magnitude or more,
> > but it leaves you open to the possibility above)
>
> > >of course the SPI clock and LFSR clocks are global
> > >clocks as well
>
> > ... good...
>
> > just a guess but on the information given, it looks plausible to me.
>
> > - Brian
>
> Hi Brian,
>
> the story goes even more fascinating (or frustrating)...
>
> first about Actel - their Logic Cell is NOT LUT based, so the
> LUT input transition glitches can not happen (no LUT!) but
> actel cell has NO DEDICATED flip-flop, and flip flops are
> configured out of logic, and have severe restrictions on
> configuration and routing, FF with enable and clear are
> made out 2 cells if CLR signal is not driven by global clock
> sometimes 4 cells are used to make 1 single flip flop.
>
> the use of global clocks in actel, sometimes its not
> "order of magnitude" difference but simple OK vs FAIL 100% issue
>
> case: 64 bit shift register (no enable just shift), clocked with CLEAN
> clock at 4mhz
>
> work 100% when FPGA is almost empty (no matter what signal drivers
> shift reg clock)
> fails 100% when FPGA is >90% and shift clock is ruouted with local
> connects
>
> PROVEN. this is also explanaibale, and actel has special appnote for
> this (clock skew handling)
> ==
> now to my clocking issue
>
> after taking a break I tried to eliminate things from the problem, so
> I stopped shifting data
> into the SPI shift register. this however made no difference, and when
> i looked again
> it was also explanaible as my test counter value was decoded in
> external AR MCU
> but the bytes holding the counter value did never get back into the
> FPGA!
>
> so to summarize again:
>
> 1) ARM9 SW has counter, that is used to generate 8 byte encrypted
> token
> 2) those 8 bytes are going into FPGA over A1 parallel interface they
> are written into dual port BRAM
> 3) those 8 bytes are read by AVR over SPI interface
> 4) AVR decodes those bytes, it also decodes the counter from step 1,
> NO ERROR ever here
> 5) AVR writes 3 bytes to FPGA SPI shift register
> 6) AVR strobes to load LFSR, and set one time flag that prevents
> further LFSR loads
> 7) ARM9 sends packets in loop (encrypted counter)
>
> now, the counter value NEVER exist inside FPGA
> the data passed via FPGA is not decoded there
> the data passed via FPGA is not used by the logic responsible for the
> load/enable of the LFSR
>
> still at some certain counter value, the LFSR does get corrupted!!
> those values are repeatable, they are not random, that is each time
> the ARM9 counter is
> restarted then at exactly same counter values the LFSR is corrupted.
> those values are however different for different PCB+bitstream
> combinations
>
> 8) AVR puts FPGA into main mode
> 9) ARM9 sends any packets any number of hours LFSR corruption no
> longer happens! no single errror seen
>
> errors happen at [7] at const numbers of counter
> error NEVER happen at [9] while streaming random data for hours..
>
> so there is no different transitions on the load input of the LFSR at
> all, still there is repeatable dependancy
> on the data stream that only passes through FPGA
>
> eeee... [8] what happens there?
>
> well after main mode the AVR no longer collects data from FPGA and no
> longer decrypts it.
> but that should no have any influence as the decrypt result wasnt
> passing into the FPGA anyway.
>
> there is one more difference,
> after [8] the LFSR is enabled for 8 clocks lonfer for each packet from
> A1 interface
>
> but the LFSR enable/load signals do not share any logic with any of
> the data lines !!
>
> Ok, when found out that the counter data is not passing into the load
> input at all, i did take a walk
> and coffee break, and did write a list of options that can be tested,
> list with 6 items, so will work
> them out one by one
>
> my bet is that I need add delay on the LFSR enable signal, there is no
> explanation why it should
> be used as it is already a FF in the same clock domain as the LFSR
> clock, but all other items
> on my list of possible problems are even less likely (or harder to
> test)
>
> Antti

status: ALL ISSUES SOLVED

I wonder how many guesses what the problem really was? :)

I check one item from my list, what made no difference.
luckuly i did not continue with my lists, as the real problem was not
there anyway.

sure, pure human error, there WAS dependancy on the data being pushed
into FPGA
there should not have been but it was, because some signal had wrong
name.

the same design error was already in intitial xilinx prototype a year
ago but
was never seen as it only happened 1:256 at startup

while converting to Actel, i first reduced decode from 8 to 4 bits
getting 1:16 errors
and later to 3 bit getting 1:8 errors

when I made my test with counter and got errors at some counter value,
i did
not print out the data bytes (8 byte encrypted) as I assumed them to
be random
but if i would have printed them out anyway, i would have seen at that
any time
when error happend 3 bits from 8 byte had constant value.

that 3 bit value caused the LFSR enable to be of wrong duration.

but, fixing it wasnt still so easy. After seeing the problem i fixed
the it.
then did make BIT file, and 2 different PCB boards did not work at
all :(

!?

after that I managed to get the micro-SD card with the test program
corrupted
so badly that if insert that SD into card reader on Vista then Vista
explorer HANGS
(need power off !!) on XP it just cant access the card.

ok, I get another sd card, put the test program onto it,

and I see again the same errors ??
after really really fixing the VHDL

I did rerun synplify and designer many times, to be sure
they really generate new bit file, still the same error was there!

guessed already?
sure the Actel Flashprogramming tool had remembered wrong location for
the bit file, so I used the wrong one.

when the fixed bit file really got into the FPGA, then it worked as it
was supposed

Antti
hope the thread wasnt so entirely boring :)

Article: 130944
Subject: Use of floating point numbers in xilinx EDK .........
From: nivesh <rai.nivesh@gmail.com>
Date: Sun, 6 Apr 2008 05:31:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
In my project the values are floating point. Since these floats take
huge memory we have taken an SDRAM controller . These values are input
to a custom peripheral which is linked to Microblaze through FSL. I
have declared a float array which contains the input values.When i try
to read these values using printf in C code then i only get the first
value as correct output and rest all comes as some random symbols ( #,
space etc).... Can anyone please help me guiding how can I handle
floats in EDK ..........Any sort of related help is
welcome........... :)

Article: 130945
Subject: Re: Examples for Spartan3 StarterKit
From: "Jaime Andres Aranguren Cardona" <jaac@nospam-sanjaac.com>
Date: Sun, 6 Apr 2008 11:01:38 -0500
Links: << >>  << T >>  << A >>
Hi,

This is what your link returns;

¡Objeto no encontrado!
El enlace requerido no ha sido localizado en este servidor. Si usted 
proporcionó el enlace de manera manual le solicitamos que por favor revise 
los datos e intentelo de nuevo.

Por favor contacte con el webmaster en caso de que usted crea que existe un 
error en el servidor.

Error 404
tokisworld.org
Sun Apr 6 18:01:06 2008
Apache/2.0.53 (Linux/SUSE)

-- 

Jaime Andres Aranguren C.
SanJaaC Electronics
Soluciones en DSP
www.sanjaac.com


"Thorsten Kiefer" <webmaster@nillakaes.de> escribió en el mensaje 
news:47f6653f$0$581$6e1ede2f@read.cnntp.org...
> Hi,
> I'm currently developing some examples for the
> Spartan3 StarterKit from digilent.
> Maybe this is interesting for newbies.
> I know that they are not spectacular at the moment.
> You can leave me a comment if you want.
>
> http://tokisworld.org/spartan3/
>
> Regards
> Thorsten
> 



-- 
Posted via a free Usenet account from http://www.teranews.com


Article: 130946
Subject: Re: Xilinx inferred FIFOs
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Sun, 6 Apr 2008 10:33:44 -0700
Links: << >>  << T >>  << A >>
> You do need to use the appropriate version for V4 with the fixes (which I 
> believe is any 9.X or later).

I have version 9.2 and can't find any documentation on inferring FIFOs,
synchronous or asynchronous, unless you consider instantiating a primitive
such as FIFO18 and the like as inference.

Brad Smallridge
Ai Vision




Article: 130947
Subject: Re: Spartan3 JTAG flash In System Programming over Ethernet
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Sun, 06 Apr 2008 21:14:31 +0200
Links: << >>  << T >>  << A >>
cpandya@yahoo.com writes:

> If there is already a ready made solution for this then that will help
> us.

I've made a programmer that works over ethernet. I've been modifying
it over the last few years to get the cost down. I will make it into a
product if there is a demand for such a programmer. I can program
fpga's (altera and xilinx), as well as spi devices, i2c, and microchip
microcontrollers. It can also program several flash devices attached
to other processors etc which have a jtag interface.

I use it under linux, and the benefit is that you don't need a driver
other than the network driver that is available with most (if not all)
operating systems. 

Would there be any interest in such a programmer, or will most users
want to stick with the programmers provided by the vendors?


Petter

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 130948
Subject: Re: Xilinx inferred FIFOs
From: austin <austin@xilinx.com>
Date: Sun, 06 Apr 2008 12:14:33 -0700
Links: << >>  << T >>  << A >>
Brad,

Yes,  sorry about that.  Not all synthesis is equal when it comes to 
recognizing the IP blocks.  And, a lot of it is too new to be supported 
today.

I am aware of a lot of work by the XST folks, as well as by our 
partners, to recognize things like FIFO's, DSP48's, etc. automatically 
without having to specifically instantiate the blocks.

I was concentrating on the known silicon V4 FIFO bug with the empty/full 
flags that was resolved by adding a small amount of external logic to 
get around the issue.

The full hardware fix was implemented in V5, so that structure needed no 
special treatment.

The V5 verification and characterization also learned many lessons from 
V4, and the overall release quality was improved a great deal. The FXT 
release just last week, is the finest ever (IMHO) by Xilinx, with now 
the complete solution platform released all at the same time.  The three 
videos of the sophisticated pcbs that were built to showcase these apps 
are testament to the "whole enchilada" being ready to go on day one.

At the ITRS TWG group meeting near Bonn last week (where I was), it was 
interesting to educate people that "it ain't your daddy's FPGA anymore..."

The 65nm V5 family is only second to Intel's 65nm product offering in 
complexity and process sophistication (and perhaps we are, in fact 
first, since Hi-K is only in their 45nm line).  They have dual core, we 
have dual core.  They have neat IP, we have neat IP.  They have some 
large die (with > 1 billion devices), and so do we.

Austin

Article: 130949
Subject: Re: Xilinx inferred FIFOs
From: Frank Buss <fb@frank-buss.de>
Date: Sun, 6 Apr 2008 22:33:13 +0200
Links: << >>  << T >>  << A >>
austin wrote:

> The 65nm V5 family is only second to Intel's 65nm product offering in 
> complexity and process sophistication (and perhaps we are, in fact 
> first, since Hi-K is only in their 45nm line).  They have dual core, we 
> have dual core.  They have neat IP, we have neat IP.  They have some 
> large die (with > 1 billion devices), and so do we.

The difference between Xilinx and Intel chips is that the decimal point for
the price of the Xilinx parts is at the wrong position :-)

I would like to use more FPGAs, but most of the time a fast CPU or
microcontroller and maybe a small external FPGA, is cheaper and solves the
problem, too.

The PSoC concept from Cypress looks interesting: Lots of high-level analog
and digital blocks, which can be connected at runtime and a fast CPU, all
in a cheap and low power package:

http://tinyurl.com/43qz49

Of course, you can't compare this to a Virtex, with which you can do high
speed and parallel calculations, but for many products a small FPGA with a
small CPU, some integrated analog components and standard interfaces, like
I2C, USB, ethernet etc., would be nice.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search