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 126075

Article: 126075
Subject: Re: FPGA for hobby use
From: Guenter Dannoritzer <kratfkryksqq@spammotel.com>
Date: Wed, 14 Nov 2007 16:30:17 +0100
Links: << >>  << T >>  << A >>
cs_posting@hotmail.com wrote:
> On Nov 14, 9:46 am, Herbert Kleebauer <k...@unibwm.de> wrote:
> 
>> Sadly the same can't be
>> said about the current Xilinx software (schematic editor + simulator),
>> so we will try to stay as long as possible with the X3000 chips and the
>> old Xilinx DOS software (with ViewLogic schematic entry + simulator).
> 
> The real problem is your insistence on using schematic entry for
> things of moderate complexity.
> 
> Learn a hardware description language and your life will be much
> easier.

... and after knowing your configuration, use a Makefile to run
implementation and say good bye to the gui.

http://www.dilloneng.com/documents/downloads/gen_ise_sh/

Cheers,

Guenter

Article: 126076
Subject: Re: FPGA for hobby use
From: John Adair <g1@enterpoint.co.uk>
Date: Wed, 14 Nov 2007 07:31:14 -0800
Links: << >>  << T >>  << A >>
I am pleased to have such a positive response to one of our products.

I am also pleased to say that as of this week Rev1.1 is shipping to
customers. The major change is the programing headers are changes to
2x7 2mm headers compatible with our own Prog2 cable and all of the
Xilinx cables with 2x7 ribbon cable. We also now have a limited stock
of Darnaw1 with XC3S1600E and XC3S1200 (I GRADE) fitted. They are not
on the shop website as yet but are available to anyone that needs the
different variants. Pricing etc are listed on our enginering web
pages.

I would also welcome any feedback on Darnaw1 from anyone that has seen
the product as we prepare to start the Darnaw2, and maybe even the
Darnaw3, designs. These wouldn't replace Darnaw1 but will cover
slightly different application areas albeit with the aim of a
compatible footprint within the product family.

John Adair
Enterpoint Ltd.

On 14 Nov, 14:46, Herbert Kleebauer <k...@unibwm.de> wrote:
> A few month ago I asked for a recommendation for FPGA (not a ready to use demo board)
> which could be handled with simple home equipment. I got the link to:
>
> http://www.enterpoint.co.uk/moelbryn/darnaw1.html
>
> We ordered a few samples and did some experimenting. Here the documentation
> for a simple 16 bit CPU implemented on the DARNAW1. It includes also a step by
> step introduction which should allow anybody still unfamiliar with FPGA design
> to implement the demo in less than a hour.
>
> ftp://137.193.64.130/pub/mproz/mproz3_e.pdf (documentation)ftp://137.193.64.130/pub/mproz/mproz3.zip   (documentation + schematics)
>
> Conclusion:
> The board is great, not just an other demo board, but rather a package
> converter from the FPG ball grid to a pin grid array with the necessary
> voltage converters and program flash on board. Sadly the same can't be
> said about the current Xilinx software (schematic editor + simulator),
> so we will try to stay as long as possible with the X3000 chips and the
> old Xilinx DOS software (with ViewLogic schematic entry + simulator).



Article: 126077
Subject: Re: FPGA for hobby use
From: MikeShepherd564@btinternet.com
Date: Wed, 14 Nov 2007 15:50:06 +0000
Links: << >>  << T >>  << A >>
>The real problem is your insistence on using schematic entry for
>things of moderate complexity.
>
>Learn a hardware description language and your life will be much
>easier.

I'd agree with that, as practical advice.

Long-term, perhaps we'll expect better graphical tools.  We have
text-based languages now partly because they are easier to define
accurately and because they exploit our familiarity with complex text
written in linear fashion (over several pages), so it's a practical
way to keep a complex design under control and to write it down.

We don't (yet) have comparable graphical tools, but perhaps that will
come.  I'm not sure the Mona Lisa would be as good if Leonardo had
made it with a text-based graphics description language or that
Beethoven's Fifth Symphony has the same appeal when experienced as a
hex dump of the WAV file.

Article: 126078
Subject: Re: Xilinx Encrypted bit file
From: austin <austin@xilinx.com>
Date: Wed, 14 Nov 2007 07:59:42 -0800
Links: << >>  << T >>  << A >>
Amal,

An unencrypted bit file is 3 to 7% 1's (97 to 93% 0's) typically.

An encrypted bit file is roughly 50% 1's and 0's.

Real easy to tell them apart.

Austin

Article: 126079
Subject: Xilinx Virtex-II Newbie
From: Andrew Ganger <Andrew.G@yahoo.co.uk>
Date: Wed, 14 Nov 2007 16:15:28 +0000
Links: << >>  << T >>  << A >>
Hello,

I am in some way a newbie in getting things to run on an FGPA, so I 
would be helpful if someone could help me a little bit out how to get 
started.

I have implemented a simple processor architecture in VHDL and I 
successfully simulated it with Modelsim. Now my next goal would be
to get this processor running on a Xilinx Virtex-II PMC FPGA board.

For synthesis I am going to use Xilinx ISE 7.1i. So to see if the
processor on the FPGA is doing what it should do I could use Chipscope
and the Jtag interface. However, I am a little bit lost with the 
following tasks.

1) I had some kind for simple RAM for simulation. How can I implement 
this RAM correctly so that it be sythesizable and will correctly run on
the FPGA?

2) When I start the processor, I should have my instructions loaded into
the Instruction RAM? How can I do this, really no clue :(

I am sorry for these basis questions, but I would be thankful if someone
could give me a hint where and how to start!

Many thanks!!
Andi



Article: 126080
Subject: Re: Xilinx Virtex-II Newbie
From: Andrew Ganger <Andrew.G@yahoo.co.uk>
Date: Wed, 14 Nov 2007 16:48:55 +0000
Links: << >>  << T >>  << A >>

> 1) I had some kind for simple RAM for simulation. How can I implement 
> this RAM correctly so that it be sythesizable and will correctly run on
> the FPGA?
> 
> 2) When I start the processor, I should have my instructions loaded into
> the Instruction RAM? How can I do this, really no clue :(

I am just reading the XST userguide. There it says that with version 
8.1i it is possible to directly specify data with the RAM module or
load it from an external source. IN addition it says the multiple write 
ports in the RAM are supported from version 8.1 on. UNfortuantely I just 
have version 7.1 and I should have a RAM that has 4 read ports and 2 
write ports? Is that somehow to realise with ISE 7.1 or do I need to 
upgrade to version 8.1?

Many thanks,
Andrew


Article: 126081
Subject: Xilinx ISE Timing Report Question
From: Peter Klemperer <ftpeter@gmail.com>
Date: Wed, 14 Nov 2007 17:23:57 -0000
Links: << >>  << T >>  << A >>
Hi,

I have a question about Xilinx post-P&R static timing reports.  I
understand most of the constraints listed in the timing report, but
some of them don't appear in my UCF and have me a bit confused.

Could anyone tell me what the time groups J_CLK and U_CLK are and why
they are configured this way?  I can't find any mention of these in
the documentation.  I've attached a bit of my .twr to the bottom of
the post.  I've seen them in several project so my guess is that they
have something to do with using chipscope or that these are the names
of some sort of global clock net.

Thanks in advance,
Peter

--------------------------------------------------------------------------------
  Constraint                                | Requested  | Actual
| Logic
                                            |            |
| Level
--------------------------------------------------------------------------------
  TS_J_TO_J = MAXDELAY FROM TIMEGRP "J_CLK" | 30.000ns   | 11.588ns
| 2
   TO TIMEGRP "J_CLK" 30 ns                 |            |
|
--------------------------------------------------------------------------------
  TS_U_TO_J = MAXDELAY FROM TIMEGRP "U_CLK" | 15.000ns   | 4.473ns
| 1
   TO TIMEGRP "J_CLK" 15 ns                 |            |
|
--------------------------------------------------------------------------------
  TS_U_TO_U = MAXDELAY FROM TIMEGRP "U_CLK" | 15.000ns   | 1.496ns
| 0
   TO TIMEGRP "U_CLK" 15 ns                 |            |
|
--------------------------------------------------------------------------------
  PATH "TS_U_TO_D_path" TIG                 | N/A        | N/A
| N/A
--------------------------------------------------------------------------------
  PATH "TS_J_TO_D_path" TIG                 | N/A        | 6.921ns
| 32
--------------------------------------------------------------------------------
  PATH "TS_D_TO_J_path" TIG                 | N/A        | 5.117ns
| 5
--------------------------------------------------------------------------------


Article: 126082
Subject: USR_ACCESS_VIRTEX4 usage
From: Jan Pech <no@spam.please>
Date: Wed, 14 Nov 2007 18:34:19 +0100
Links: << >>  << T >>  << A >>
Hello all,

I would like to use the USR_ACCESS_VIRTEX4 primitive to access an
additional bitstream stored in a config  flash. The situation is
following:
* I have a master FPGA (Virtex-4FX) and a slave FPGA (Spartan-3A). The
slave FPGA is located on an additional board and it is NOT daisy-chained
with the master one.
* Master FPGA gets configured out of platform flash in master serial
mode.
* I need to configure even the slave FPGA. The only non-volatile source
of its configuration data is the platform flash connected to the master
FPGA.

I used STARTUP_VIRTEX4 primitive to take control over the CCLK and DONE
signals. While generating bitstream I used the "-g DONE_cycle:KEEP"
option. From my measurements of the interface between flash and
Virtex-4, this part of the design works fine. I fully control the
signals, DONE does not go high anywhere in the middle, and flash sends
me additional bitstream data.

To access additional bitstream I instantiated the USR_ACCESS_VIRTEX4
primitive, but here is the problem. Even though I see the data on the
DIN input of the Virtex-4, the DATAVALID output of the
USR_ACCESS_VIRTEX4 primitive never goes high. So that I am unable to
reach this data inside the Virtex-4 FPGA.

The Virtex-4 Libraries Guide for HDL Design says: The PROM should
contain a packet of data with the USR_ACCESS register as the target. I
generated my PROM file using iMPACT simply putting two bitstreams into
single MCS file what is probably wrong. I think my MCS should contain
normal master FPGA bitstream followed by the slave FPGA bitsream with
target set to USR_ACCESS. Is there any way how to set target for the
second bitsream in MCS to USR_ACCESS so that I could access it from my
master FPGA?

If I am trying to do something impossible, is there another approach how
read slave configuration data from platform flash using master FPGA? I
cannot do it simply controlling flash pins, as they are not connected to
IO pins of the FPGA but to dedicated configuration pins only.

Thanks for advices,
Jan


Article: 126083
Subject: Re: Xilinx Virtex-II Newbie
From: Andrew Ganger <Andrew.G@yahoo.co.uk>
Date: Wed, 14 Nov 2007 18:02:34 +0000
Links: << >>  << T >>  << A >>
Andrew Ganger wrote:
> UNfortuantely I just 
> have version 7.1 and I should have a RAM that has 4 read ports and 2 
> write ports? Is that somehow to realise with ISE 7.1 or do I need to 
> upgrade to version 8.1?

Mixed something up, my Register File should have 4 read ports and two 
write ports :)

Article: 126084
Subject: Re: FPGA for hobby use
From: cs_posting@hotmail.com
Date: Wed, 14 Nov 2007 10:04:29 -0800
Links: << >>  << T >>  << A >>
On Nov 14, 10:50 am, MikeShepherd...@btinternet.com wrote:

> Long-term, perhaps we'll expect better graphical tools.  We have
> text-based languages now partly because they are easier to define
> accurately and because they exploit our familiarity with complex text
> written in linear fashion (over several pages), so it's a practical
> way to keep a complex design under control and to write it down.
>
> We don't (yet) have comparable graphical tools, but perhaps that will
> come.  I'm not sure the Mona Lisa would be as good if Leonardo had
> made it with a text-based graphics description language

The problem is that you seem to want to use the graphical layout to
represent the wrong aspect of the design.

Schmetic level and HDL level entry both try to capture functionality,
but HDL level is far superior for managing the the kinds of complexity
involved in accomplishing real functionality.

If you want to do something graphical, do it at the system level.  Use
something like Matlab & Simluink to describe what you want the FPGA to
do, and then use the HDL generation plugins. to make the FPGA actually
do it.

The possible case where FPGA-vendor-tool schematic entry might still
make sense is if you do all the actual implementation modules in HDL
code, but make your top level a system-block-diagram sort of
schematic.

Otherwise you're just trying to represent in messy pictures what is
much clearer in text.


Article: 126085
Subject: Re: Xilinx ISE Timing Report Question
From: Jochen <JFrensch@HarmanBecker.com>
Date: Wed, 14 Nov 2007 10:19:20 -0800
Links: << >>  << T >>  << A >>
On 14 Nov., 18:23, Peter Klemperer <ftpe...@gmail.com> wrote:
Hi Peter,

> Hi,
>   <snip>
> I've seen them in several project so my guess is that they
> have something to do with using chipscope or that these are the names
> of some sort of global clock net.
>
> Thanks in advance,
> Peter
>

using chipscope, you should see an edif-netlist like "icon.edn" or
something
like this, that will integrated automatically within your toplevel
design running ngdbuild.
I guess, you'll find a file called "icon.ncf" within the same
directory

If you have a look at it's content with a simple editor, you should
find said timing-constraints - and they will be automatically linked
to your design, too.

They are needed to guarantee chipscope's functionality (JTAG-
clock,...)


hope, it helps,
Jochen



Article: 126086
Subject: Re: Xilinx Virtex-II Newbie
From: Nathan Bialke <nathan.bialke@gmail.com>
Date: Wed, 14 Nov 2007 18:19:38 -0000
Links: << >>  << T >>  << A >>
What you are asking for is outside the abilities of the Virtex-II
FPGA. Since the FPGA only contains dual-ported memories (either
SelectRAM-based or BlockRAM-based), there is no possible way to map
such a HDL description to the FPGA device.

You'll have to figure out a mechanism to multiplex the read/write
ports such that you have less than or equal to two ports (be they
read, write, or read/write ports).

Good luck - welcome to the world of FPGA engineering.

- Nathan

On Nov 14, 10:02 am, Andrew Ganger <Andre...@yahoo.co.uk> wrote:
> Andrew Ganger wrote:
> > UNfortuantely I just
> > have version 7.1 and I should have a RAM that has 4 read ports and 2
> > write ports? Is that somehow to realise with ISE 7.1 or do I need to
> > upgrade to version 8.1?
>
> Mixed something up, my Register File should have 4 read ports and two
> write ports :)


Article: 126087
Subject: Re: Non-volatile FPGA in a small package
From: Kris Vorwerk <kris.vorwerk@gmail.com>
Date: Wed, 14 Nov 2007 10:26:51 -0800
Links: << >>  << T >>  << A >>
Hi,

On Nov 8, 8:43 am, "John_H" <newsgr...@johnhandwork.com> wrote:
> "Kryvor" <kris.vorw...@gmail.com> wrote in message
>
> > (It looks as thoughActelcarries some smaller ProASICPlus parts in a
> > TQFP 100 package.  Those parts have 2 PLLs and are Flash-based
> > [reprogrammable, immune to SEUs, etc.].)
>
> The Flash cells may be imune to SEUs but the active logic certainly isn't.
> SEUs "tend" to be noticed in SRAM cells first but registers are also
> affected by the same radiation for FPGAs of any flavor as well as ASICs and
> other standard parts.

Fair enough.

It would have been more accurate for me to say that Actel's Flash
FPGAs are immune to configuration loss due to single-event errors.

In the interest of thoroughness, Actel's Flash FPGAs *have* undergone
substantial FIT testing and are quite resilient (compared to SRAM
devices) in terms of their alpha and neutron radiation handling:
http://www.actel.com/products/solutions/ser/


cheers,
K.


Article: 126088
Subject: Re: Xilinx ISE Timing Report Question
From: Peter Klemperer <ftpeter@gmail.com>
Date: Wed, 14 Nov 2007 10:31:01 -0800
Links: << >>  << T >>  << A >>
Thanks Jochen,  that did it for me.  I should have grep'd for it.

--Peter

On Nov 14, 12:19 pm, Jochen <JFren...@HarmanBecker.com> wrote:
> On 14 Nov., 18:23, Peter Klemperer <ftpe...@gmail.com> wrote:
> Hi Peter,
>
> > Hi,
> >   <snip>
> > I've seen them in several project so my guess is that they
> > have something to do with using chipscope or that these are the names
> > of some sort of global clock net.
>
> > Thanks in advance,
> > Peter
>
> using chipscope, you should see an edif-netlist like "icon.edn" or
> something
> like this, that will integrated automatically within your toplevel
> design running ngdbuild.
> I guess, you'll find a file called "icon.ncf" within the same
> directory
>
> If you have a look at it's content with a simple editor, you should
> find said timing-constraints - and they will be automatically linked
> to your design, too.
>
> They are needed to guarantee chipscope's functionality (JTAG-
> clock,...)
>
> hope, it helps,
> Jochen



Article: 126089
Subject: Re: FPGA for hobby use
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 14 Nov 2007 10:33:54 -0800
Links: << >>  << T >>  << A >>
<cs_posting@hotmail.com> wrote in message 
news:1195063469.146499.122220@v3g2000hsg.googlegroups.com...
>
> Otherwise you're just trying to represent in messy pictures what is
> much clearer in text.
>
Dear Whoeveryouare,
That statement may well be true in your case. However, I know of engineers 
who say exactly the reverse!

Don't get me wrong, IMHO, large projects with experienced engineers are best 
served by using a HDL. That said, there are circumstances where I believe 
schematics have an advantage.

You already mentioned one of these cases, when you wrote about a block 
diagram. Another case is when an engineer is first starting to use FPGAs. 
This is the situation being discussed in this thread. The use of schematics 
allows some rookie engineers to get a better grasp of how their circuits are 
realised in the FPGA. The schematic can clearly show individual FFs and 
gates. I'd suggest this is particularly true when engineeers are coming from 
a software background. The schematic design flow is so different from 
software development, it forces a different 'hardware' mindset. When these 
same engineers 'progress' to RTL, the experience they've gained from the 
circuit structures they've built with schematics is very useful.

YMMV.
Cheers, Syms. 



Article: 126090
Subject: Re: Xilinx Encrypted bit file
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 14 Nov 2007 10:46:06 -0800
Links: << >>  << T >>  << A >>
"austin" <austin@xilinx.com> wrote in message 
news:fhf61e$o351@cnn.xilinx.com...
> Amal,
>
> An unencrypted bit file is 3 to 7% 1's (97 to 93% 0's) typically.
>
> An encrypted bit file is roughly 50% 1's and 0's.
>
> Real easy to tell them apart.
>
> Austin
Hi Austin,
What if the FPGA design had all the BRAMs initialised to 1's? ;-)
Cheers, Syms. 



Article: 126091
Subject: Re: FPGA for hobby use
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 15 Nov 2007 07:48:18 +1300
Links: << >>  << T >>  << A >>
Herbert Kleebauer wrote:
> A few month ago I asked for a recommendation for FPGA (not a ready to use demo board)
> which could be handled with simple home equipment. I got the link to:
> 
> http://www.enterpoint.co.uk/moelbryn/darnaw1.html
> 
> We ordered a few samples and did some experimenting. Here the documentation
> for a simple 16 bit CPU implemented on the DARNAW1. It includes also a step by
> step introduction which should allow anybody still unfamiliar with FPGA design
> to implement the demo in less than a hour.
> 
> ftp://137.193.64.130/pub/mproz/mproz3_e.pdf  (documentation)
> ftp://137.193.64.130/pub/mproz/mproz3.zip    (documentation + schematics)
> 
> Conclusion: 
> The board is great, not just an other demo board, but rather a package
> converter from the FPG ball grid to a pin grid array with the necessary
> voltage converters and program flash on board. Sadly the same can't be 
> said about the current Xilinx software (schematic editor + simulator), 
> so we will try to stay as long as possible with the X3000 chips and the
> old Xilinx DOS software (with ViewLogic schematic entry + simulator).

So, hundreds of man months of SW effort have seen a nett-step backwards ?
Can you elaborate on some of the drawbacks, and perhaps Xilinx can fix 
them ?

-jg


Article: 126092
Subject: Re: FPGA for hobby use
From: Mike Treseler <mike_treseler@comcast.net>
Date: Wed, 14 Nov 2007 11:01:16 -0800
Links: << >>  << T >>  << A >>
Herbert Kleebauer wrote:

> The board is great, not just an other demo board, but rather a package
> converter from the FPG ball grid to a pin grid array with the necessary
> voltage converters and program flash on board. Sadly the same can't be 
> said about the current Xilinx software (schematic editor + simulator), 
> so we will try to stay as long as possible with the X3000 chips and the
> old Xilinx DOS software (with ViewLogic schematic entry + simulator).

Maybe John will do an altera board someday.
The quartus schematic capture is clean and solid.
The free simulator is also limited to waves,
but the licensed version has a very usable version of modelsim
and an rtl viewer that covers verilog and vhdl.

        -- Mike Treseler

Article: 126093
Subject: Re: Xilinx Encrypted bit file
From: austin <austin@xilinx.com>
Date: Wed, 14 Nov 2007 11:02:41 -0800
Links: << >>  << T >>  << A >>
Symon,

Even with all BRAM's to 1's, the files will still look really very
different in terms of one's density!

One of the side-effects on a good encryption method is that it makes the
data look like "noise."

So, what they need is a way to tell the difference between "noise" and a
unencrypted bit file.

You could play it through a sound card, and you could immediately tell
the difference, for example.

(I can see the assembly line taking 'dance to the bit stream breaks')

Or, you could display the bit file on a monitor with 24 bit color, in
.bmp format (or .tiff, or whatever) and the encrypted files will look
like grey splotches of many colored pixels, and the unencrypted bit
files will look like structures of some sorts (not "noise" at all!).

By the way, I use this last method to evaluate true random number
generators, as your brain can view a big (1760 X 1024 X 24 bit) picture
and almost instantly "see" non-random behavior ... must have something
to do with us all coming from hunters on the veld two million years ago ...

If you display them fast enough, you can even make a "movie" or if you
play them fast enough, a symphony.

Austin

Article: 126094
Subject: Block-ram FIFO in Xilinx
From: "zlotawy" <paraliczb@NO_SPAM_orange.pl>
Date: Wed, 14 Nov 2007 20:37:55 +0100
Links: << >>  << T >>  << A >>
Hello,
I have generated a block-ram based FIFO queue (2 independent clocks, 2
inputs, 1 output) with the use of Core Generator. In the creator I used the
36 bit data bus. Is it possible to parameterize this variable?
I think, that the Xilinx doesn't give such possibility. The generated code:

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
-- synthesis translate_off
Library XilinxCoreLib;
-- synthesis translate_on
ENTITY fifa IS
 port (
 din: IN std_logic_VECTOR(35 downto 0);
 rd_clk: IN std_logic;
 rd_en: IN std_logic;
 rst: IN std_logic;
 wr_clk: IN std_logic;
 wr_en: IN std_logic;
 dout: OUT std_logic_VECTOR(35 downto 0);
 empty: OUT std_logic;
 full: OUT std_logic);
END fifa;

ARCHITECTURE fifa_a OF fifa IS
-- synthesis translate_off
component wrapped_fifa
 port (
 din: IN std_logic_VECTOR(35 downto 0);
 rd_clk: IN std_logic;
 rd_en: IN std_logic;
 rst: IN std_logic;
 wr_clk: IN std_logic;
 wr_en: IN std_logic;
 dout: OUT std_logic_VECTOR(35 downto 0);
 empty: OUT std_logic;
 full: OUT std_logic);
end component;

-- Configuration specification
 for all : wrapped_fifa use entity
XilinxCoreLib.fifo_generator_v4_1(behavioral)
  generic map(
   c_has_int_clk => 0,
   c_rd_freq => 1,
   c_wr_response_latency => 1,
   c_has_srst => 0,
   c_has_rd_data_count => 0,
   c_din_width => 36,
   c_has_wr_data_count => 0,
   c_full_flags_rst_val => 1,
   c_implementation_type => 2,
   c_family => "virtex2p",
   c_use_embedded_reg => 0,
   c_has_wr_rst => 0,
   c_wr_freq => 1,
   c_underflow_low => 0,
   c_has_meminit_file => 0,
   c_has_overflow => 0,
   c_preload_latency => 1,
   c_dout_width => 36,
   c_rd_depth => 1024,
   c_default_value => "BlankString",
   c_mif_file_name => "BlankString",
   c_has_underflow => 0,
   c_has_rd_rst => 0,
   c_has_almost_full => 0,
   c_has_rst => 1,
   c_data_count_width => 10,
   c_has_wr_ack => 0,
   c_use_ecc => 0,
   c_wr_ack_low => 0,
   c_common_clock => 0,
   c_rd_pntr_width => 10,
   c_use_fwft_data_count => 0,
   c_has_almost_empty => 0,
   c_rd_data_count_width => 10,
   c_enable_rlocs => 0,
   c_wr_pntr_width => 10,
   c_overflow_low => 0,
   c_prog_empty_type => 0,
   c_optimization_mode => 0,
   c_wr_data_count_width => 10,
   c_preload_regs => 0,
   c_dout_rst_val => "0",
   c_has_data_count => 0,
   c_prog_full_thresh_negate_val => 1020,
   c_wr_depth => 1024,
   c_prog_empty_thresh_negate_val => 3,
   c_prog_empty_thresh_assert_val => 2,
   c_has_valid => 0,
   c_init_wr_pntr_val => 0,
   c_prog_full_thresh_assert_val => 1021,
   c_use_fifo16_flags => 0,
   c_has_backup => 0,
   c_valid_low => 0,
   c_prim_fifo_type => "1kx36",
   c_count_type => 0,
   c_prog_full_type => 0,
   c_memory_type => 1);
-- synthesis translate_on
BEGIN
-- synthesis translate_off
U0 : wrapped_fifa
  port map (
   din => din,
   rd_clk => rd_clk,
   rd_en => rd_en,
   rst => rst,
   wr_clk => wr_clk,
   wr_en => wr_en,
   dout => dout,
   empty => empty,
   full => full);
-- synthesis translate_on

END fifa_a;


There are 2 parameters: c_din_width =>36  and c_dout_width => 36.  I can't
use here values greater than 36. What is the use of this parameters? Can I
change this parameters values to i.e. 20?
I would like to use the queue with different sizes of the data bus. Is it a
good solution to create a maximum size data bus and use it to write there
smaller data?
Or maybe it is better to create a 1bit queue, and with the use of GENERATE
command generate N 1 bit queues to have a N-bit queue?

Device is Virtex2Pro.

Regards,
zlotawy



Article: 126095
Subject: Re: FPGA for hobby use
From: Ray Andraka <ray@andraka.com>
Date: Wed, 14 Nov 2007 14:41:49 -0500
Links: << >>  << T >>  << A >>
cs_posting@hotmail.com wrote:

>
> Otherwise you're just trying to represent in messy pictures what is
> much clearer in text.
> 

I don't entirely agree with you.  Good use of hierarchy makes schematic 
far clearer than text for many if not most circuits.  It also 
facilitates reuse, maintainability etc.  The problem is most schematic 
users don't make very good use of hierarchy at all, and the tools are of 
little help there as well.  Back when I used Viewlogic, I had 
constructed a rather extensive library of 1 and 2 bit slices, of 
components built up from those slices and of macro functions.  I had 
honed that system well enough so that the top level designs looked like 
signal processing block diagrams, and as you worked down through the 
hierarchy you got to progressively simpler elements.  That methodology 
also allowed me to put placement constraints in the design.

The real advantages to using an HDL are:
1) they are readable with just a text editor, and therefore can be 
archived without also archiving the tool and the computer.  This also 
means version control is easier.

2) It is far easier to build parameterized objects with an HDL.  This 
provides a means for faster reuse.  This is mainly a tools issue, since 
nothing was really made to automate parameterized schematics.

3) Currently, the tools for HDL designs are far superior to the 
schematic tools, mainly because that is where the effort has been 
focused over the last decade.

Article: 126096
Subject: Re: FPGA for hobby use
From: John Adair <g1@enterpoint.co.uk>
Date: Wed, 14 Nov 2007 11:45:59 -0800
Links: << >>  << T >>  << A >>
One of these days we might have an Altera based product. We have been
asked by various people to do one and my very able team could turn an
Altera product very quickly if we decided to do that. The current
record by the team for delivering a working main development board to
a customer is 18 days from start of development. Most of our
competitors couldn't probably get the spec written in that time. That
product is still in the range and shipping.

It's a kind of funny thing that over the years Enterpoint at various
points in time actually did more Altera based work that Xilinx. A long
time ago we considered joining Altera's ACAP but Xilinx's equivalent
at the time came up as a better deal at the same time and the rest is
history.

Back to the present and we have an exciting roll out of products
coming. We have just about caught up on things we have promised for a
while and December and January will start to see the release of things
we have not talked about yet in any detail. Some very different
concepts to appear as well as the nearly predictable. Our own PCIE
core is in beta and working well on our PCIE Broaddown4 and that will
drive PCIE based boards that are the predictable end of the set of
releases coming.

John Adair
Enterpoint Ltd.


On 14 Nov, 19:01, Mike Treseler <mike_trese...@comcast.net> wrote:
> Herbert Kleebauer wrote:
> > The board is great, not just an other demo board, but rather a package
> > converter from the FPG ball grid to a pin grid array with the necessary
> > voltage converters and program flash on board. Sadly the same can't be
> > said about the current Xilinx software (schematic editor + simulator),
> > so we will try to stay as long as possible with the X3000 chips and the
> > old Xilinx DOS software (with ViewLogic schematic entry + simulator).
>
> Maybe John will do an altera board someday.
> The quartus schematic capture is clean and solid.
> The free simulator is also limited to waves,
> but the licensed version has a very usable version of modelsim
> and an rtl viewer that covers verilog and vhdl.
>
>         -- Mike Treseler



Article: 126097
Subject: Re: FPGA for hobby use
From: cs_posting@hotmail.com
Date: Wed, 14 Nov 2007 11:46:42 -0800
Links: << >>  << T >>  << A >>
On Nov 14, 1:33 pm, "Symon" <symon_bre...@hotmail.com> wrote:

> You already mentioned one of these cases, when you wrote about a block
> diagram. Another case is when an engineer is first starting to use FPGAs.
> This is the situation being discussed in this thread. The use of schematics
> allows some rookie engineers to get a better grasp of how their circuits are
> realised in the FPGA. The schematic can clearly show individual FFs and
> gates. I'd suggest this is particularly true when engineeers are coming from
> a software background. The schematic design flow is so different from
> software development, it forces a different 'hardware' mindset. When these
> same engineers 'progress' to RTL, the experience they've gained from the
> circuit structures they've built with schematics is very useful.

I still think this is a mistake on an order comparable to trying to
use LabView to wire up assembly language instructions into a useful
program.

There's a time and a place to learn about real circuit implementations
of simple computational structures and of state machines - made of
gates and flip flops, and of gates and flip flops made of
transistors.  But that's not effectively how things work in an FPGA.
FPGAs run on logic equations, which are going to be re-interpreted
into the proprietary assortment of available doodads by the tools
anyway.

Nobody should be instantiating discrete gates in an FPGA (iobuffers
and other special ones exempted), instead they should be writing
equations - HDL code - that accomplish the intended function in a
concise and comprehensible way.

The problem with schematic entry is that it's instantation-centric.
If you are using your schematic at a block diagram level to wire up
big modules, that's good.  But if you are using it at a detailed level
to instantiate gates in a real project (or even HDL to instantiate
them), that's just silly.   You should be writing equations - but how
do you enter equations in a schematic?

This is probably one reason why state machine graphical entry exists -
it's still arguably a non-serious tool, but at least it's focused on
what the circuit is supposed to do, not the obscuring detail of how it
does it.



Article: 126098
Subject: Re: FPGA for hobby use
From: cs_posting@hotmail.com
Date: Wed, 14 Nov 2007 11:52:58 -0800
Links: << >>  << T >>  << A >>
On Nov 14, 2:41 pm, Ray Andraka <r...@andraka.com> wrote:
> cs_post...@hotmail.com wrote:
>
> > Otherwise you're just trying to represent in messy pictures what is
> > much clearer in text.
>
> I don't entirely agree with you.  Good use of hierarchy makes schematic
> far clearer than text for many if not most circuits.

Yes, good use.  That's why I suggested a top-level block diagram
schematic made of HDL coded modules could be good.  And yes, it's
extensible down the hierarchy to a degree.  But sooner or later you
will get down to HDL modules, either your own or the vendor mega
function libraries.

> The problem is most schematic
> users don't make very good use of hierarchy at all

Exactly.

> The real advantages to using an HDL are:
> 1) they are readable with just a text editor, and therefore can be
> archived without also archiving the tool and the computer.  This also
> means version control is easier.

That says to me that the graphical block diagrams should be complexity
constrained:

- they should be legible on a letter sized piece of paper (as well as
on your monitor without scrolling)

- they shouldn't take more than an hour to re-create from the paper,
either in a buggy new graphical tool or in a textual HDL

It's when people try to create complexity in the graphical
representations - by not using hierarchy - that their unsuitability
shows up.


Article: 126099
Subject: Re: FPGA for hobby use
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 14 Nov 2007 12:23:54 -0800
Links: << >>  << T >>  << A >>
Hi Chris,
I added some comments below.

<cs_posting@hotmail.com> wrote in message
news:1195069602.205639.51830@o3g2000hsb.googlegroups.com...
> On Nov 14, 1:33 pm, "Symon" <symon_bre...@hotmail.com> wrote:
>
>> You already mentioned one of these cases, when you wrote about a block
>> diagram. Another case is when an engineer is first starting to use FPGAs.
>> This is the situation being discussed in this thread. The use of
>> schematics
>> allows some rookie engineers to get a better grasp of how their circuits
>> are
>> realised in the FPGA. The schematic can clearly show individual FFs and
>> gates. I'd suggest this is particularly true when engineeers are coming
>> from
>> a software background. The schematic design flow is so different from
>> software development, it forces a different 'hardware' mindset. When
>> these
>> same engineers 'progress' to RTL, the experience they've gained from the
>> circuit structures they've built with schematics is very useful.
>
> I still think this is a mistake on an order comparable to trying to
> use LabView to wire up assembly language instructions into a useful
> program.
>
> There's a time and a place to learn about real circuit implementations
> of simple computational structures and of state machines - made of
> gates and flip flops, and of gates and flip flops made of
> transistors.  But that's not effectively how things work in an FPGA.
> FPGAs run on logic equations, which are going to be re-interpreted
> into the proprietary assortment of available doodads by the tools
> anyway.
>
OK, but the point I'm trying to make is that schematics can be a good tool
to learn how the circuit is implemented _in_an_FPGA_. The FPGA
implementation is different than, for example, a discrete logic
implementation or an ASIC implementation. When a designer knows how the
circuit will be implementated he can tailor his design to fit. The
correlation between what is drawn in the schematic and what ends up in the
FPGA's LUTs is closer than with an equivalent RTL design, helping the
beginner see which structures are good, and which are bad.
>
> Nobody should be instantiating discrete gates in an FPGA (iobuffers
> and other special ones exempted), instead they should be writing
> equations - HDL code - that accomplish the intended function in a
> concise and comprehensible way.
>
Usually this is true. However, some designs require extracting the fastest
possible timing from the FPGA, or the smallest resource usage. A designer
can code the design in RTL appropriately and hope the synthesis tool gets
the message or they can instantiate FPGA primitives in their RTL. It's my
contention that a designer who has a grounding of the underlying structure
of the FPGA will be at an advantage, and one way to get that knowledge is to
design as a beginner with schematics.
>
> The problem with schematic entry is that it's instantation-centric.
>
Which is my point. Sometimes instantiation is useful for the reasons I
outlined above.
>
> If you are using your schematic at a block diagram level to wire up
> big modules, that's good.  But if you are using it at a detailed level
> to instantiate gates in a real project (or even HDL to instantiate
> them), that's just silly.   You should be writing equations - but how
> do you enter equations in a schematic?
>
Again, a fair point. But the context of this thread is education, not 'real
projects', which, I think, changes what is 'good'.
>
> This is probably one reason why state machine graphical entry exists -
> it's still arguably a non-serious tool, but at least it's focused on
> what the circuit is supposed to do, not the obscuring detail of how it
> does it.
>
>
I've never used state machine graphical entry, I can't comment.

Regards, Syms.






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