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
2019JanFebMar2019

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 156250

Article: 156250
Subject: chip-to-chip serial comms
From: Charlie Martin <tickranch@gmail.com>
Date: Fri, 24 Jan 2014 08:05:28 -0800 (PST)
Links: << >>  << T >>  << A >>
What do you recommendation for serial communications between FPGA chips? We=
 have one FPGA sending configuration information to multiple other FPGAs. T=
he FPGAs will be on different boards. The bandwidth is low, although the me=
ssage transfer needs to be accomplished in well under a microsecond. We hav=
e a limited number of lines, so an addressable serial scheme is desirable.=
=20

Previously we have "rolled our own" asynchronous serial protocol and corres=
ponding firmware, and transmitted via LVDS. The drawbacks are that a lot of=
 effort went into both developing the firmware, and solving signal integrit=
y challenges.

I'm wondering what common practices or standard solutions exist? With the g=
eneric transceivers now available, what out-of-the box techniques are there=
 for using them? Are there cookbook approaches to designing the signal circ=
uitry? SRIO seems like just the solution, but I really can't tell if it is =
straightforward to integrate (e.g. the API for the Xilinx Serial RapidIO co=
re is huge).

Thanks for your thoughts,
Charlie

Article: 156251
Subject: Re: chip-to-chip serial comms
From: MK <mk@nospam.co.uk>
Date: Fri, 24 Jan 2014 17:36:25 +0000
Links: << >>  << T >>  << A >>
On 24/01/2014 16:05, Charlie Martin wrote:
> What do you recommendation for serial communications between FPGA chips? We have one FPGA sending configuration information to multiple other FPGAs. The FPGAs will be on different boards. The bandwidth is low, although the message transfer needs to be accomplished in well under a microsecond. We have a limited number of lines, so an addressable serial scheme is desirable.
>
> Previously we have "rolled our own" asynchronous serial protocol and corresponding firmware, and transmitted via LVDS. The drawbacks are that a lot of effort went into both developing the firmware, and solving signal integrity challenges.
>
> I'm wondering what common practices or standard solutions exist? With the generic transceivers now available, what out-of-the box techniques are there for using them? Are there cookbook approaches to designing the signal circuitry? SRIO seems like just the solution, but I really can't tell if it is straightforward to integrate (e.g. the API for the Xilinx Serial RapidIO core is huge).
>
> Thanks for your thoughts,
> Charlie
>
Not quite enough timing info to know if this is a good bet but I would 
start with SPI, then move to SPI via LVDS, then 4 data line SPI over 
LVDS - should be good for 12Mbyte/s easily (nice slow 25MHz clock) but 
could possibly get up to 50Mbyte/s.

But if you are seriously contemplating SRIO then you are perhaps hoping 
for an order faster than this which would be way out of my league.

Michael Kellett

Article: 156252
Subject: Re: my first microZed board
From: Frank Buss <fb@frank-buss.de>
Date: Sat, 25 Jan 2014 00:05:11 +0100
Links: << >>  << T >>  << A >>
John Larkin wrote:
> 
> All that DDRx ram and microSim and Ethernet and stuff is a nuisance to
> design and test. For a tad under $200, it's a bargain.

Nice. Not as nice and cheap as the Parallella board, but at least you
can already buy it.

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

Article: 156253
Subject: Re: chip-to-chip serial comms
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 24 Jan 2014 23:38:26 +0000 (GMT)
Links: << >>  << T >>  << A >>
Charlie Martin <tickranch@gmail.com> wrote:
> I'm wondering what common practices or standard solutions exist? With the
> generic transceivers now available, what out-of-the box techniques are
> there for using them?  Are there cookbook approaches to designing the
> signal circuitry?  SRIO seems like just the solution, but I really can't
> tell if it is straightforward to integrate (e.g.  the API for the Xilinx
> Serial RapidIO core is huge).

If you're on Xilinx, have a look at Aurora for the physical layer.  I
haven't used it but it looks a useful building block for a bits-in, bits-out
solution.

The things you have to worry about (in the general case) are:
Crossing clock domains (one transmit clock, plus a clock per receive lane)
Line encoding (8b/10b, 128b/130b or similar)
Stuffing idle symbols when you don't have any data
PLLs and clocking (locking receiver clock on startup, plus handling
powerdown if you ever do that)
Packetisation/reassembly/alignment
Error checking/correction/retransmits

I don't have any experience with RapidIO, but I think it's either that or
roll your own solution (as we did).  Most of the other serial formats
(ethernet etc) have too high latency.

Theo

Article: 156254
Subject: Re: my first microZed board
From: John Larkin <jlarkin@highlandtechnology.com>
Date: Fri, 24 Jan 2014 15:53:40 -0800
Links: << >>  << T >>  << A >>
On Sat, 25 Jan 2014 00:05:11 +0100, Frank Buss <fb@frank-buss.de>
wrote:

>John Larkin wrote:
>> 
>> All that DDRx ram and microSim and Ethernet and stuff is a nuisance to
>> design and test. For a tad under $200, it's a bargain.
>
>Nice. Not as nice and cheap as the Parallella board, but at least you
>can already buy it.

$99 is amazing for that board. One can ignore the Epiphany thing, I
guess.




-- 

John Larkin         Highland Technology, Inc

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com


Article: 156255
Subject: Re: Prog3 - USB Programming Solution for Xilinx
From: federico.corradi@gmail.com
Date: Sat, 25 Jan 2014 01:01:33 -0800 (PST)
Links: << >>  << T >>  << A >>
Il giorno gioved=EC 4 febbraio 2010 18:02:49 UTC+1, John Adair ha scritto:
> It's not been tried on a Linux system here as yet but as it is driver
> compatible with the Xilinx cable there is a good chance it will work
> anywhere their cable or software works (with the usual Linux
> restrictions).
>=20
> John Adair
> Enterpoint Ltd.
>=20
> On 4 Feb, 16:40, "jt_eaton" <z3qmtr45@n_o_s_p_a_m.gmail.com> wrote:
> > >Prog3 operates with Xilinx software and does not need anything else to
> > >use this programmer.
> >
> > >John Adair
> > >Enterpoint Ltd.
> >
> > Does it run under linux?
> >
> > --------------------------------------- =A0 =A0 =A0 =A0
> > Posted throughhttp://www.FPGARelated.com

Yes it does,
I am using it with ubuntu 12.04, with cable drivers. It works perfectly.
If you need more hints I'll be glad to let you know how to install cable dr=
ivers and etc..

Article: 156256
Subject: Re: Xilinx BSCAN primitives proper use
From: drummer_man <vmnrao@gmail.com>
Date: Sat, 25 Jan 2014 02:51:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, February 6, 2008 11:31:22 PM UTC-8, mh wrote:
> On Feb 4, 7:22 pm, posedg...@yahoo.com wrote:
> >  > I myself was confronted with such a situation and I asked this
> >
> > > question on this forum, and was contacted by S3 group who later sent
> > > me the tool. I used it and found it an excellent tool.
> > > HTH
> >
> > Seems the unmodified tool is still missing on the S3 site:http://www.s3group.com/system_ic/gnat/download_gnat/
> >
> > Could you upload it somewhere?
> 
> 
> 
> Hi,
> I had a correspondence with S-3 group and they allowed me to freely
> distribute Gnat tool with a comment that they don't support this tool
> any more.
> 
> So, Any one who need this tool may contact me directly.
> 
> /MH

Article: 156257
Subject: Re: Xilinx BSCAN primitives proper use
From: drummer_man <vmnrao@gmail.com>
Date: Sat, 25 Jan 2014 02:52:53 -0800 (PST)
Links: << >>  << T >>  << A >>
MH or anyone who still has a copy of the GNAT tool, please post a link for me (and others). Much appreciated!

V


> 
> Hi,
> I had a correspondence with S-3 group and they allowed me to freely
> distribute Gnat tool with a comment that they don't support this tool
> any more.
> 
> So, Any one who need this tool may contact me directly.
> 
> /MH


Article: 156258
Subject: Re: embedded RAM vs. registers
From: alb <alessandro.basili@cern.ch>
Date: Sat, 25 Jan 2014 14:54:23 +0100
Links: << >>  << T >>  << A >>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Andy, my apologies for such a delayed reply.

On 1/22/2014 1:27 AM, jonesandy@comcast.net wrote:
[]
> Most "automatic" conversion of logic from LUTs to RAMs involves
> using the RAMs like ROMs, preloaded with constant data during 
> configuration. Flash based FPGAs from MicroSemi do not have the 
> ability to preload their BRAMs during "configuration." There is no 
> "configuration" phase at/during startup during which they could 
> automatically be preloaded.

That is quite a good piece of information. So I can stop looking for
any 'automatic' mode. Moreover any RAM logic I may profit of would
need to be configured after power up via external commands. While this
is certainly possible, it requires system modifications which are not
so often welcome.

[]
> If you have several identical slow speed interfaces (e.g. UARTs,
> SPI, I2C, etc.) that could happily run with an effective clock rate
> of a fraction of your system clock rate, look at C-slow
> optimization to reduce utilization. There are a few coding tricks
> that ease translating a single-channel module into a multi-channel,
> C-slowed module capable of replacing multiple copies of the
> original.

Thanks for the hint. The way I understood this is inserting say 2
registers for each register, increasing latency without affecting the
functionality, but allowing retiming. I haven't understood why they
call it /C/-slowing and why /C/-registers...

> Retiming can be combined with C-slowing (the two are very 
> synergystic) to enable the original clock rate to be increased, 
> recovering some of the original per-channel performance.
> 
> Repipelining can be combined with C-slowing (also synergystic) to 
> hide original design latency, thus recovering some of the
> per-channel performance without increasing the system clock rate.

These techniques seem indeed attractive when it comes to speed
optimization, but in my specific case I simply wanted to free some
core logic usage to allow other functionality to be added to the
design. Since these 'features' are given at such a later stage in the
design phase, it seems very unlikely it will not require an
architectural change.

That's the main reason why I was looking at some 'automatic' feature
to profit of onboard resources without the need to change too much
RTL. I guess there's no easy fix for this.

Al
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS48IPAAoJEPaNonZWXERQgW0IAORzqR8iX68j9u+QZEjZ67ID
C3eHGLk4LddDtrX+Uf2TOYoxH0OV1gvMHqrPdbEg83sBrQtSK62ScnKLNpNnQL7y
ViOnBxuyMn3IbJEp7L7MV31WjFUnhX+k4eUiRMAAEUnOUVIp5VFxlb1eUPqZr/XG
KlLRKw1+a3X1i1UaO2SjlIx+p1/JVZ4fvDb+HWALnbdwFE2edktf/6APl0bee8gB
sOWdTIS88NDscSZtjZBokFIOPDGoo95lOdx2bioR4WYeckZdMyOFjStrzKcDQaZb
tjZKUisyeyOIkjlVur4Vso4XaG4oK+adJgNTq30B2beF+LJkx+cA1soFZgxn5WA=
=qYUI
-----END PGP SIGNATURE-----

Article: 156259
Subject: Re: embedded RAM vs. registers
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 25 Jan 2014 16:07:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
alb <alessandro.basili@cern.ch> wrote:

(snip)

(snip)

> Thanks for the hint. The way I understood this is inserting say 2
> registers for each register, increasing latency without affecting the
> functionality, but allowing retiming. I haven't understood why they
> call it /C/-slowing and why /C/-registers...

I only learned about C-slow a year or two ago, and wasn't sure
why it was so different from the pipelining that computer 
designers did in the 1960's and 1970's. 

And yes, I don't know what the C is for.

-- glen

Article: 156260
Subject: Re: my first microZed board
From: mac <acolvin@efunct.com>
Date: Sat, 25 Jan 2014 17:06:51 +0000 (UTC)
Links: << >>  << T >>  << A >>
>> Nice. Not as nice and cheap as the Parallella board, but at least you
>> can already buy it.

> $99 is amazing for that board. One can ignore the Epiphany thing, I
> guess.


Can one? What would I need to access the FPGA fabric? Assuming I ever get
my board...
I suppose I'll need to acquire some recent Xilinx IDE.
-- 
mac the naïf

Article: 156261
Subject: Re: my first microZed board
From: John Devereux <john@devereux.me.uk>
Date: Sat, 25 Jan 2014 20:18:56 +0000
Links: << >>  << T >>  << A >>
John Larkin <jlarkin@highlandtechnology.com> writes:

> On Sat, 25 Jan 2014 00:05:11 +0100, Frank Buss <fb@frank-buss.de>
> wrote:
>
>>John Larkin wrote:
>>> 
>>> All that DDRx ram and microSim and Ethernet and stuff is a nuisance to
>>> design and test. For a tad under $200, it's a bargain.
>>
>>Nice. Not as nice and cheap as the Parallella board, but at least you
>>can already buy it.
>
> $99 is amazing for that board. One can ignore the Epiphany thing, I
> guess.

The "Epiphany thing" sounds like what you have been advocating, for the
last few years. Many cores, a core for each task etc. Now you can *buy*
one, you are not interested? :)


-- 

John Devereux

Article: 156262
Subject: Re: embedded RAM vs. registers
From: jonesandy@comcast.net
Date: Mon, 27 Jan 2014 08:37:16 -0800 (PST)
Links: << >>  << T >>  << A >>
From what I understand, C-slowing originated as a state-space transform. I =
don't know what C stands for either.

The earliest reference I have seen for its application to digital circuits =
is:

C. Leiserson, F. Rose, and J. Saxe, "Optimizing synchronous circuitry by re=
timing," Proceedings of the 3rd Caltech Conference On VLSI, pp. 87-116, Mar=
ch 1983

I do not have access to the paper, but it is cited in many later papers as =
the initial work in the application of C-slowing to digital circuits. From =
the title, I would assume that they employed C-slowing to remove all single=
-clock-cycle feeback paths, which otherwise cannot be retimed.

Andy

Article: 156263
Subject: Programming a Digilent S6 Carrier (Spartan 6
From: "mnentwig" <24789@embeddedrelated>
Date: Wed, 29 Jan 2014 07:34:44 -0600
Links: << >>  << T >>  << A >>
Hi,

I'm programming the Flash memory in a Digilent "S6 carrier" board. It takes
a long time, about 8 minutes.

The configuration file size is 1484404 bytes
and I'd expect it to take around 10s at a cable clock frequency of 1.6
Mbit/s. Not 467s.



Under "edit attached flash properties" there is an option "Data width: 1".
What does this mean?
If I set it to the maximum of 4, I get a warning

>> "The data width you assigned is 4 but the PROM file (.mcs) is generated
in a x1 mode. Please double-check your assignments or it may not work
properly."

but I don't see any options when the .mcs file is created to change that.
The Flash memory is N25Q128, and the electrical connections can be found
here, top of page 5: 
http://www.digilentinc.com/Data/Products/FMC-CARRIER-S6/FMC_Carrier-S6_rm.pdf
What does this option mean?



A log from an upload is pasted below.
I've tried to create the .mcs file for smaller memory (16M instead of 128M)
but it seems to make no difference.

Is there anything I can do to speed this up? With my favourite "Papilio Pro
board", reflashing takes about 10 s (the bitstream is 1/6 the size, but
still...)
Verify is off.

Direct upload to the FPGA is of course an option, but it's one thing less
to worry if I can take the board off the shelf after a week and simply plug
it in.

Cheers

Markus

INFO:iMPACT - Digilent Plugin: Plugin Version: 2.4.3
INFO:iMPACT - Digilent Plugin: Opening device : "SN:xxx".
INFO:iMPACT - Digilent Plugin: User Name: FMC-Carrier-S6
INFO:iMPACT - Digilent Plugin: Product Name: FMC Carrier-S6
INFO:iMPACT - Digilent Plugin: Serial Number: xxx
INFO:iMPACT - Digilent Plugin: Product ID: 00F0000D
INFO:iMPACT - Digilent Plugin: Firmware Version: 0306
INFO:iMPACT - Digilent Plugin: JTAG Port Number: 0
INFO:iMPACT - Digilent Plugin: JTAG Clock Frequency: 1600000 Hz
INFO:iMPACT - Current time: 29.01.2014 15:17:36
PROGRESS_START - Starting Operation.
Maximum TCK operating frequency for this device chain: 0.
Validating chain...
Boundary-scan chain validated successfully.
'1': SPI access core not detected. SPI access core will be downloaded to
the device to enable operations.
INFO:iMPACT - Downloading core file
C:/Xilinx/14.7/ISE_DS/ISE/spartan6/data/xc6slx45_spi.cor.
'1': Downloading core...
 LCK_cycle = NoWait.
LCK cycle: NoWait
done.
'1': Reading status register contents...
INFO:iMPACT:2219 - Status register values:
INFO:iMPACT - 0011 1100 1110 1100 
INFO:iMPACT:2492 - '1': Completed downloading core to device.
'1': IDCODE is '20ba18' (in hex).
'1': ID Check passed.
 '1': IDCODE is '20ba18' (in hex).
'1': ID Check passed.
 '1': Erasing Device.
'1': Using Sector Erase.
'1': Programming Flash.
'1':Programming in x1 mode.
'1': Programmed successfully.
INFO:iMPACT - '1': Flash was programmed successfully.
 LCK_cycle = NoWait.
LCK cycle: NoWait
INFO:iMPACT - '1': Checking done pin....done.
'1': Programmed successfully.
PROGRESS_END - End Operation.
************** Elapsed time =    466 sec. *****************
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 156264
Subject: Re: Programming a Digilent S6 Carrier (Spartan 6
From: GaborSzakacs <gabor@alacron.com>
Date: Wed, 29 Jan 2014 10:17:05 -0500
Links: << >>  << T >>  << A >>
mnentwig wrote:
> Hi,
> 
> I'm programming the Flash memory in a Digilent "S6 carrier" board. It takes
> a long time, about 8 minutes.
> 
> The configuration file size is 1484404 bytes
> and I'd expect it to take around 10s at a cable clock frequency of 1.6
> Mbit/s. Not 467s.
> 

Unfortunately there's a lot of overhead in programming the SPI flash,
so the cable bit rate is not the bitstream data rate.  8 minutes may
be about right.  Depending on the cable, you might up the bit rate
to 12 MHz (requires a USB 2.0 HS slot).  I've found that many BIOSes
default to setting the USB 2.0 ports to standard speed or "fast" rather
than high-speed.  You'd need to open the BIOS setup to see if that's
a problem on your computer.

> 
> 
> Under "edit attached flash properties" there is an option "Data width: 1".
> What does this mean?
> If I set it to the maximum of 4, I get a warning
> 
>>> "The data width you assigned is 4 but the PROM file (.mcs) is generated
> in a x1 mode. Please double-check your assignments or it may not work
> properly."
> 
> but I don't see any options when the .mcs file is created to change that.
> The Flash memory is N25Q128, and the electrical connections can be found
> here, top of page 5: 
> http://www.digilentinc.com/Data/Products/FMC-CARRIER-S6/FMC_Carrier-S6_rm.pdf
> What does this option mean?
> 

This is the way the SPI flash is read.  Most modern SPI flash chips
support dual or quad readout mode (x2 or x4).  This makes the time to
configure the FGPA from flash go down by half or quarter from the
standard SPI serial (x1) time.  However the bitstream must match the
data width of the PROM file.  To use x4 mode, you need to have an
appropriate SPI device that supports it, e.g. Winbond W25Qxxx.  Then
you have to go back to ISE and set the bit width to 4 when you generate
the bitstream (note - this is not done from Impact).  Finally when you
generate the .mcs file, you need to select the x4 mode.

In any case this only reduces the startup time of the FPGA.  It has
no effect on the time to program the Flash.  Programming is always
done 1-bit serially.

> 
> 
> A log from an upload is pasted below.
> I've tried to create the .mcs file for smaller memory (16M instead of 128M)
> but it seems to make no difference.
> 
> Is there anything I can do to speed this up? With my favourite "Papilio Pro
> board", reflashing takes about 10 s (the bitstream is 1/6 the size, but
> still...)
> Verify is off.
> 
> Direct upload to the FPGA is of course an option, but it's one thing less
> to worry if I can take the board off the shelf after a week and simply plug
> it in.
> 
> Cheers
> 
> Markus
> 
> INFO:iMPACT - Digilent Plugin: Plugin Version: 2.4.3
> INFO:iMPACT - Digilent Plugin: Opening device : "SN:xxx".
> INFO:iMPACT - Digilent Plugin: User Name: FMC-Carrier-S6
> INFO:iMPACT - Digilent Plugin: Product Name: FMC Carrier-S6
> INFO:iMPACT - Digilent Plugin: Serial Number: xxx
> INFO:iMPACT - Digilent Plugin: Product ID: 00F0000D
> INFO:iMPACT - Digilent Plugin: Firmware Version: 0306
> INFO:iMPACT - Digilent Plugin: JTAG Port Number: 0
> INFO:iMPACT - Digilent Plugin: JTAG Clock Frequency: 1600000 Hz
> INFO:iMPACT - Current time: 29.01.2014 15:17:36
> PROGRESS_START - Starting Operation.
> Maximum TCK operating frequency for this device chain: 0.
> Validating chain...
> Boundary-scan chain validated successfully.
> '1': SPI access core not detected. SPI access core will be downloaded to
> the device to enable operations.
> INFO:iMPACT - Downloading core file
> C:/Xilinx/14.7/ISE_DS/ISE/spartan6/data/xc6slx45_spi.cor.
> '1': Downloading core...
>  LCK_cycle = NoWait.
> LCK cycle: NoWait
> done.
> '1': Reading status register contents...
> INFO:iMPACT:2219 - Status register values:
> INFO:iMPACT - 0011 1100 1110 1100 
> INFO:iMPACT:2492 - '1': Completed downloading core to device.
> '1': IDCODE is '20ba18' (in hex).
> '1': ID Check passed.
>  '1': IDCODE is '20ba18' (in hex).
> '1': ID Check passed.
>  '1': Erasing Device.
> '1': Using Sector Erase.
> '1': Programming Flash.
> '1':Programming in x1 mode.
> '1': Programmed successfully.
> INFO:iMPACT - '1': Flash was programmed successfully.
>  LCK_cycle = NoWait.
> LCK cycle: NoWait
> INFO:iMPACT - '1': Checking done pin....done.
> '1': Programmed successfully.
> PROGRESS_END - End Operation.
> ************** Elapsed time =    466 sec. *****************
> 	   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

-- 
Gabor

Article: 156265
Subject: Re: Programming a Digilent S6 Carrier (Spartan 6
From: "mnentwig" <24789@embeddedrelated>
Date: Wed, 29 Jan 2014 09:42:00 -0600
Links: << >>  << T >>  << A >>
Hi Gabor,

thanks for the explanation. 
I'll try a different USB port tomorrow, didn't think of that. I may have
plugged it into a mouse-/keyboard port, not the USB 3.0 socket.
I was also wondering about the startup time, not that it's a problem in my
application. About 5 secs, seemed rather slow. Might give it a shot and set
4x mode, just out of curiosity. 

Cheers

Markus	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 156266
Subject: Re: Programming a Digilent S6 Carrier (Spartan 6
From: GaborSzakacs <gabor@alacron.com>
Date: Thu, 30 Jan 2014 14:33:15 -0500
Links: << >>  << T >>  << A >>
mnentwig wrote:
> Hi Gabor,
> 
> thanks for the explanation. 
> I'll try a different USB port tomorrow, didn't think of that. I may have
> plugged it into a mouse-/keyboard port, not the USB 3.0 socket.
> I was also wondering about the startup time, not that it's a problem in my
> application. About 5 secs, seemed rather slow. Might give it a shot and set
> 4x mode, just out of curiosity. 
> 
> Cheers
> 
> Markus	   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

While going to x4 mode definitely speeds things up, 5 seconds
does sound like a long time unless you're using a very large
part.  Options for the SPI clock speed are also bitgen
parameters.  The default CCLK rate is rather slow, 2 MHz IIRC.
You can set this as high as the actual flash part can go,
but you need to take into account the wide (+/- 50% IIRC)
frewuency tolerance of the internally generated CCLK.  So
while going to x4 mode increases config speed by a factor of 4,
increasing the clock speed from default could give up to a
factor of 50 for newer FPGA families and SPI parts.  Doing
both can speed things up by as much as 200 times.

-- 
Gabor

Article: 156267
Subject: PathFinder Source Code (in C)
From: ZIAD ABUOWAIMER <ziadasic@gmail.com>
Date: Fri, 31 Jan 2014 15:37:13 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi Guys,

I am currently working on FPGA accelerators for PathFinder algorithm (FPGA =
routing algorithm). I am planning to use a HW/SW co-design to speedup the a=
lgorithm but I need a C code implementation of the PathFinder to start with=
 since my project is to accelerate the algorithm in FPGA and I don't have e=
nough time to implemented from scratch. I appreciate your help if you can g=
ive me the c code or tell me where I can get it.

thanks,

Ziad


Article: 156268
Subject: Re: PathFinder Source Code (in C)
From: KJ <kkjennings@sbcglobal.net>
Date: Sat, 1 Feb 2014 06:14:18 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, January 31, 2014 6:37:13 PM UTC-5, ZIAD ABUOWAIMER wrote:
>=20
> I am currently working on FPGA accelerators for PathFinder algorithm (FPG=
A routing algorithm). I am planning to use a HW/SW co-design to speedup the=
 algorithm but I need a C code implementation of the PathFinder to start wi=
th since my project is to accelerate the algorithm in FPGA and I don't have=
 enough time to implemented from scratch. I appreciate your help if you can=
 give me the c code or tell me where I can get it.
>=20

Try this link for sources...
http://lmgtfy.com/?q=3Dpathfinder+source+code

I'd suggest taking the first link from that list and read.

Kevin

Article: 156269
Subject: Verilog (Xilinx): Virtual tristate or muxes?
From: "mnentwig" <24789@embeddedrelated>
Date: Sat, 01 Feb 2014 15:48:08 -0600
Links: << >>  << T >>  << A >>
Hi,

I've got some FPGA resources that are shared, for example RAM and
multiplier.
Instead of explicitly muxing the inputs, would it make sense to use
"virtual" tristate ports in connected modules?
I'd expect that if the enabling condition is the same as in an explicit
mux, also the resulting implementation should be the same. Or not?

I haven't started any synthesis experiments yet, thought I'd ask first
(even though we all know that a couple of months in the lab can save many
hours in the library...)

Cheers

Markus	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 156270
Subject: Re: Verilog (Xilinx): Virtual tristate or muxes?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 1 Feb 2014 23:33:52 +0000 (UTC)
Links: << >>  << T >>  << A >>
mnentwig <24789@embeddedrelated> wrote:

(snip)
> I've got some FPGA resources that are shared, for example RAM and
> multiplier.

> Instead of explicitly muxing the inputs, would it make sense to use
> "virtual" tristate ports in connected modules?
> I'd expect that if the enabling condition is the same as in an explicit
> mux, also the resulting implementation should be the same. Or not?

Early FPGAs had real tristate lines inside. With scaling, they
required buffers along the way, and so most now have, as you note,
virtual tristates. (Except that I/O buffers usually have real
tristate, going off chip.)

As well as I know, virtual tristates are implemented as either
virtual wired-AND or wired-OR. (In TTL terms, open collector
or its complement.) That is probably more efficient than an
actual MUX. 

In verilog (and I presume VHDL) you can implement wired-AND or
wired-OR, and it likely synthesizes just fine. 

At some point, you should design for readability first, and let
the tools do their job. If the logic looks like tristate, where
the enables are available at the driving points, then virtual
tristate, virtual wired-AND, or virtual wired-OR are probably
best. If the select line is available close to the destination,
then MUX is probably best.

Hope this helps,

-- glen

Article: 156271
Subject: Re: PathFinder Source Code (in C)
From: dlheliski@gmail.com
Date: Sun, 2 Feb 2014 10:19:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Saturday, February 1, 2014 9:14:18 AM UTC-5, KJ wrote:
> On Friday, January 31, 2014 6:37:13 PM UTC-5, ZIAD ABUOWAIMER wrote:
>=20
> >=20
>=20
> > I am currently working on FPGA accelerators for PathFinder algorithm (F=
PGA routing algorithm). I am planning to use a HW/SW co-design to speedup t=
he algorithm but I need a C code implementation of the PathFinder to start =
with since my project is to accelerate the algorithm in FPGA and I don't ha=
ve enough time to implemented from scratch. I appreciate your help if you c=
an give me the c code or tell me where I can get it.
>=20
> >=20
>=20
>=20
>=20
> Try this link for sources...
>=20
> http://lmgtfy.com/?q=3Dpathfinder+source+code
>=20
>=20
>=20
> I'd suggest taking the first link from that list and read.
>=20
>=20
>=20
> Kevin

And every single link on the first page at least is entirely irrelevant.
For instance, the first link is broken, but appears to refer to code to com=
plete a file name path.

Go here:

http://www.eecg.toronto.edu/~jayar/software/software.html


Article: 156272
Subject: Re: Verilog (Xilinx): Virtual tristate or muxes?
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Mon, 3 Feb 2014 08:29:24 -0800
Links: << >>  << T >>  << A >>
On Sat, 01 Feb 2014 15:48:08 -0600
"mnentwig" <24789@embeddedrelated> wrote:

> Hi,
> 
> I've got some FPGA resources that are shared, for example RAM and
> multiplier.
> Instead of explicitly muxing the inputs, would it make sense to use
> "virtual" tristate ports in connected modules?
> I'd expect that if the enabling condition is the same as in an explicit
> mux, also the resulting implementation should be the same. Or not?
> 
> I haven't started any synthesis experiments yet, thought I'd ask first
> (even though we all know that a couple of months in the lab can save many
> hours in the library...)
> 
> Cheers
> 
> Markus	   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

Oh good, you've stepped into one of the long running holy wars of FPGA
design.

Respectfully, I'm going to disagree with Glen.  Yes, the tools should
be able to infer an AND/OR mux from the logic you wrote as a tristate.
But it means that you've knowingly written code that says it does one
thing and really does another.  To my mind it's... unaesthetic.  It
breaks the rule that the point of code is to tell you the programmer
what's going on, and then it should also synthesize.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 156273
Subject: Re: Verilog (Xilinx): Virtual tristate or muxes?
From: gtwrek@sonic.net (Mark Curry)
Date: Mon, 3 Feb 2014 18:24:41 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <20140203082924.045c791c@rg.highlandtechnology.com>,
Rob Gaddi  <rgaddi@technologyhighland.invalid> wrote:
>On Sat, 01 Feb 2014 15:48:08 -0600
>"mnentwig" <24789@embeddedrelated> wrote:
>
>> Hi,
>> 
>> I've got some FPGA resources that are shared, for example RAM and
>> multiplier.
>> Instead of explicitly muxing the inputs, would it make sense to use
>> "virtual" tristate ports in connected modules?
>> I'd expect that if the enabling condition is the same as in an explicit
>> mux, also the resulting implementation should be the same. Or not?
>> 
>> I haven't started any synthesis experiments yet, thought I'd ask first
>> (even though we all know that a couple of months in the lab can save many
>> hours in the library...)
>> 
>> Cheers
>> 
>> Markus	   
>> 					
>> ---------------------------------------		
>> Posted through http://www.FPGARelated.com
>
>Oh good, you've stepped into one of the long running holy wars of FPGA
>design.
>
>Respectfully, I'm going to disagree with Glen.  Yes, the tools should
>be able to infer an AND/OR mux from the logic you wrote as a tristate.
>But it means that you've knowingly written code that says it does one
>thing and really does another.  To my mind it's... unaesthetic.  It
>breaks the rule that the point of code is to tell you the programmer
>what's going on, and then it should also synthesize.

Agree with Rob here.  We just explicity use Wired-Or in our designs
for things like this.  I don't really see much use in using tristates
in RTL code, when assigning to zero (when something's not used/not needed)
is just as easy as assigning to 'z'.  And as Rob notes, you're stating
explicity what the tools are going synthesize.

Big note however, if you're using Vivado, the first versions of the tools 
didn't support Wired-Or/Wired-And.  (It's worked fine forever in ISE). 
I think they've fixed it in a recent release...

Regards,

Mark




Article: 156274
Subject: Re: Verilog (Xilinx): Virtual tristate or muxes?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 3 Feb 2014 21:24:42 +0000 (UTC)
Links: << >>  << T >>  << A >>
Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:
> On Sat, 01 Feb 2014 15:48:08 -0600
> "mnentwig" <24789@embeddedrelated> wrote:

(snip)
>> I've got some FPGA resources that are shared, for example RAM and
>> multiplier.
>> Instead of explicitly muxing the inputs, would it make sense to use
>> "virtual" tristate ports in connected modules?

(snip)
> Oh good, you've stepped into one of the long running holy wars 
> of FPGA design.
 
> Respectfully, I'm going to disagree with Glen.  Yes, the tools should
> be able to infer an AND/OR mux from the logic you wrote as a tristate.

Reading what I wrote again, I did not say that he should use tristate
over wired-OR. I mostly suggested he should write for readability.

> But it means that you've knowingly written code that says it does one
> thing and really does another.  To my mind it's... unaesthetic.  It
> breaks the rule that the point of code is to tell you the programmer
> what's going on, and then it should also synthesize.

But a large fraction of HDL code says one thing and does another,
at least if you look close enough. For one, they implement with
LUTs instead of gates.

Also behavioral form is even more different from what it
actually does, though I mostly try to write structural verilog.

Seems that the main difference betweeen tristate and wired-OR
is that the chip doesn't overheat if you pull the line in two
directions at the same time. That doesn't seem bad to me.

I believe that tristate, wired-AND, and wired-OR will all
synthesize the same way, such that one should choose based
on personal preference or personal aesthetics.  (I tried not
to emphasize one in the first post.)

I am not so sure that an actual MUX will synthesize the same.
But the tools are improving all the time, so maybe they do that
by now, too.

-- glen




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
2019JanFebMar2019

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