Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
Thanks to you too Aurelian
Marco
Aurelian Lazarut ha scritto:
> connect the mode pins to ground for '0' or leave them open (not
> connected) for a '1' logic
> Aurash
> Marco wrote:
>
> >Hi,
> >on my AD Spartan3 board I have 3 jumpers selecting the boot mode M0-2.
> >They let you connect each pin to GND, so if you place no jumper on a
> >ceretain pin think you get a high signal ('1') on that mode pin. Why?
> >I was supposed to have internal pullups only on the I/Os, enabled
> >during the configuration stage by the HSWAP_EN and not also on those
> >M0-2 pins.
> >In my board should I do it the same way or shoud I consider a connector
> >in which jumpers could link those pins to Vcc for '1' or to GND for
> >'0'?
> >Thanks,
> >Marco
> >
> >
> >
>
>
> --
> __
> / /\/\ Aurelian Lazarut
> \ \ / System Verification Engineer
> / / \ Xilinx Ireland
> \_\/\/
>
> phone: 353 01 4032639
> fax: 353 01 4640324
Article: 103901Alex - I don't usually use VHDL, but it looks to me like you have at least one serious problem in your code. You are creating a counter called buffer_write_offset which counts on the rising edge of the clock and resets on the rising edge of LATCH_IN. Do you know of any type of counter hardware that acts like this? Could you show me Xilinx primitives like FD that could be used to make such a counter? Counters should have only one edge sensitive signal, the clock. A second issue is that you're using code like: address_buffer <= ADDRESS_IN after 5ns; The synthesizer has no way to create logic that delays by a fixed number of ns. This construct may be nice for your simulations, but the delay will be ignored by synthesis. I think your code is a bit too complex. I would create a 64 bit shift register that simply shifts in one byte at a time. After 8 bytes are received, load the 64 bits into an output register for output. This is probably a dozen lines of code in Verilog. Good luck! John ProvidenzaArticle: 103902
Vivek Menon wrote: > Hi.. > I am trying to implement the Rocket I/O interface on the Xilinx > Virtex-II Pro FF672 kit from Avnet. The reference design is EDK based > and uses the powerPC. I would like to know the procedure for > implementing Rocket I/O on this board using the logic fabric ( I > presume that the power PC just slows down everything and moreover the > logic fabric would be better suited for my application). I find that using the PowerPC allows a very convenient method of running interactive tests via a serial link. It certainly is not necessary for using the RocketIO. > I am using > the Fibre channel for connection. Aurora is not an option here due to > limited licenses. The Aurora core is free, and the license has very little in the way of restrictions. It is also very easy to use, and should in my opinion be your first choice for a plain data interface. It would probably help to understand how you wish to use the interface. Are you actually attempting to implement the Fibre channel protocol, or do you mean that you are using fiber optic cables. > So one option I am currently exploring is the Architecture wizard which > gives me a HDL interface for the Rocket I/O. But I am not sure about > exactly defining the .ucf file for the different pins. If anybody has a > pointer to this problem or some sort of info on the pinouts/ucf file, > please pass it on. You need to read the "RocketIO Transceiver User Guide". That is all covered. Also, the Avnet board reference design comes with a UCF file with the correct pinouts.Article: 103903
Alex McHale wrote: > At the bottom of this post is the code. > > First, let me say that I have run this "program" through a TBW, and it > seems to simulate correctly. > > Second, I'll describe what this module does (or at least, should do). > 8 bytes (along with 5 address bits that are carried). When 8 bytes > come in, it outputs all 8 at once in a 64 bit value (again, along with > the carried 5 bit address). > > The latch line is mostly simply passed through, except that it is > additionally used to reset the buffer pointer. > > Am I making this task overly complex? If not, what's going on with it? > > When I run the "implement design" task, I get the following warnings / > errors: > > ========================================================================= > * HDL Analysis > * > ========================================================================= > Analyzing Entity <queue> (Architecture <behavioral>). > WARNING:Xst:790 - "C:/xilinx/tutorial/queue.vhd" line 46: Index > value(s) does not match array range, simulation mismatch. > INFO:Xst:1433 - Contents of array <data_buffer> may be accessed with an > index that exceeds the array size. This could cause simulation > mismatch. You data_buffer is an array of (0 to 7), but the index buffer_write_index is 4 bits, which means it can range from 0 to 15. Those two messages are trying to warn you of that potential problem. > ERROR:Xst:827 - "C:/xilinx/tutorial/queue.vhd" line 23: Signal > DATA_OUT<57> cannot be synthesized, bad synchronous description. > The DATA_OUT<57> is somewhat misleading. Really the problem is the bad synchronous description. And johnp pointed out the problem there.Article: 103904
Hi Duane, 1. The reference design is power PC based and includes the BERT test. I do not want to use that. So I thought of using the Rocket I/O implementation on the logic fabric. Also I am using the fibre optic cable. What specs to use for that? 2. The ucf file that comes with the Avnet board is for the EDK project. I am confused about converting it for ISE project. At the same time, thank you for letting me know that the Aurora core is free of charge. Let me download it and look into it. Thanks, Vivek Duane Clark wrote: > Vivek Menon wrote: > > Hi.. > > I am trying to implement the Rocket I/O interface on the Xilinx > > Virtex-II Pro FF672 kit from Avnet. The reference design is EDK based > > and uses the powerPC. I would like to know the procedure for > > implementing Rocket I/O on this board using the logic fabric ( I > > presume that the power PC just slows down everything and moreover the > > logic fabric would be better suited for my application). > > I find that using the PowerPC allows a very convenient method of running > interactive tests via a serial link. It certainly is not necessary for > using the RocketIO. > > > I am using > > the Fibre channel for connection. Aurora is not an option here due to > > limited licenses. > > The Aurora core is free, and the license has very little in the way of > restrictions. It is also very easy to use, and should in my opinion be > your first choice for a plain data interface. > > It would probably help to understand how you wish to use the interface. > Are you actually attempting to implement the Fibre channel protocol, or > do you mean that you are using fiber optic cables. > > > So one option I am currently exploring is the Architecture wizard which > > gives me a HDL interface for the Rocket I/O. But I am not sure about > > exactly defining the .ucf file for the different pins. If anybody has a > > pointer to this problem or some sort of info on the pinouts/ucf file, > > please pass it on. > > You need to read the "RocketIO Transceiver User Guide". That is all > covered. Also, the Avnet board reference design comes with a UCF file > with the correct pinouts.Article: 103905
Excellent, thank you for the reply. Like I said, I'm new to VDHL and logic programming in general. I've got breadboard experience from college, but that's it. Otherwise I'm a software developer. johnp wrote: > Alex - > > I don't usually use VHDL, but it looks to me like you have at > least one serious problem in your code. > > You are creating a counter called buffer_write_offset which counts > on the rising edge of the clock and resets on the rising edge of > LATCH_IN. > > Do you know of any type of counter hardware that acts like this? > Could you show me Xilinx primitives like FD that could be used to > make such a counter? > > Counters should have only one edge sensitive signal, the clock. > > A second issue is that you're using code like: > address_buffer <= ADDRESS_IN after 5ns; > > The synthesizer has no way to create logic that delays by a fixed > number of ns. This construct may be nice for your simulations, > but the delay will be ignored by synthesis. > > > I think your code is a bit too complex. I would create a 64 bit shift > register > that simply shifts in one byte at a time. After 8 bytes are received, > load the 64 bits into an output register for output. > > This is probably a dozen lines of code in Verilog. > > Good luck! > > John ProvidenzaArticle: 103906
I would suggest that you not think of VHDL or Verilog like a programming language. You can code it in a similar way, but I find I get poor results that way. Instead, I design in block diagrams with registers and arbitrary blocks of logic which I just specify with the logic equations. Once I am comfortable with my block diagram, I "describe" the hardware elements in a standard form for that element. After all, it is not called Vhsic Hardware DESCRIPTION Language for nothing! Registers are coded in a standard style that will produce a register with or without an enable or a reset (sync or async or both). Random logic is coded either inside the register description, or better in separate concurrent statements. This will give you signals that you can examine going into as well as out of the register for better visibility. Using the block diagram gives you more clarity of what you will be producing in the hardware. Since you are using standard templates for the logic blocks, you won't get errors about unsynthesizable statements. One other thing. I don't intend to be mean, but if you don't understand why resetting a register on a signal's rising edge is not good, then you need more training in hardware design before you continue. That may just have been a slip on your part, but if it was a mistake from lack of understanding, then your background is not sufficient to be designing digital hardware. Of course, if this is a learning exercise for you, then please ask questions. Alex wrote: > Excellent, thank you for the reply. Like I said, I'm new to VDHL and > logic programming in general. I've got breadboard experience from > college, but that's it. Otherwise I'm a software developer. > > > > johnp wrote: > > Alex - > > > > I don't usually use VHDL, but it looks to me like you have at > > least one serious problem in your code. > > > > You are creating a counter called buffer_write_offset which counts > > on the rising edge of the clock and resets on the rising edge of > > LATCH_IN. > > > > Do you know of any type of counter hardware that acts like this? > > Could you show me Xilinx primitives like FD that could be used to > > make such a counter? > > > > Counters should have only one edge sensitive signal, the clock. > > > > A second issue is that you're using code like: > > address_buffer <= ADDRESS_IN after 5ns; > > > > The synthesizer has no way to create logic that delays by a fixed > > number of ns. This construct may be nice for your simulations, > > but the delay will be ignored by synthesis. > > > > > > I think your code is a bit too complex. I would create a 64 bit shift > > register > > that simply shifts in one byte at a time. After 8 bytes are received, > > load the 64 bits into an output register for output. > > > > This is probably a dozen lines of code in Verilog. > > > > Good luck! > > > > John ProvidenzaArticle: 103907
Ed McGettigan wrote:
> Marco wrote:
> > Hi,
> > on my AD Spartan3 board I have 3 jumpers selecting the boot mode M0-2.
> > They let you connect each pin to GND, so if you place no jumper on a
> > ceretain pin think you get a high signal ('1') on that mode pin. Why?
> > I was supposed to have internal pullups only on the I/Os, enabled
> > during the configuration stage by the HSWAP_EN and not also on those
> > M0-2 pins.
> > In my board should I do it the same way or shoud I consider a connector
> > in which jumpers could link those pins to Vcc for '1' or to GND for
> > '0'?
> > Thanks,
> > Marco
> >
>
> All Xilinx devices have weak (10kohm+)internal pullups on the
> configuration mode select pins. The HSWAP_EN pin only enables/disable
> the pullup on the non-dedicated pins during configuration.
>
> If you do not connect this pin to anything else on the PCB that might
> cause a current drain (like an LED) you do not need to add a dedicate
> pullup resistor.
>
> Ed McGettigan
> --
> Xilinx Inc.
Funny a Xilinx rep would make such a mistake. Yes, these parts have an
internal pullup on the Mode pins, but it is nowhere near 10K ohms. The
data sheet specs it at between 1 and 3 kohms and on our board it is
measuring about 1 kohms. This is significant if you use pulldown
resistors thinking the pullup is very light. Using a 1 kohm pulldown
is often used when the internal pullup is 10k or more. But with the
Spartan 3 parts you need a resistor of 330 ohms or less to be sure you
pull down hard enough. Of course using jumpers will do the job. I
just wanted to clarify the 10 kohm mistake since this has caused grief
with engineers who did not read the data sheet in enough detail
themselves and relied on advice like Ed (and my FAE) gave.
Also, the details of the configuration signals IO characteristics are
much more complex that you have described. Some pins have pullups at
all times like the Mode pins, at least until configuration is done.
Other signals can have pullup, no pullup, or totempole outputs
depending on configuration parameters. The data sheet does a poor job
of putting all this in one place and you will have to hunt around to
figure out what has pullups and what is programmable. Basically, you
need to read all 206 pages of the data sheet very carefully to make
sure you get all the info on how to configure the part and the details
on the IOs.
Article: 103908John_H wrote: > What was "teased" in the webcast and not followed up was a new board on the > horizon using the largest Spartan 3E: the XC3S1600E. .... > There are lots of wants among the people who visit the newsgroup regularly. With all the competition going on between A and X, I'd like to see more movement in the category "Largest FPGA with free tool support". A, with the Cyclone II EP2C70 has been the leader for a very long time now. X only offers the Spartan 3E XC3S1600E is less than half the size of the EP2C70. One can only hope that X jumps on the opportunity with Virtex 5. TommyArticle: 103909
backhus wrote:
> Mike, interesting result from Quartus. At least it seems to do some
> optimization.
It may be of academic interest,
but binary encoding is the clear winner here,
as it usually is in small cases.
Even in large cases the difference is
mostly one of speed, not area.
> Is there anything in the synthesis report that gives
> information about what exactly was done to the FSM?
looks like it pitched 7 and 11:
http://home.comcast.net/~mike_treseler/pseudo.pdf
http://home.comcast.net/~mike_treseler/pseudo_states.pdf
-- Mike Treseler
Article: 103910Tommy, It is extremely unusual for someone who wishes to use the largest part to care about free software. I believe this category might be re-labeled: "fastest way to throw money away." Make no mistake, Xilinx is a business, not a charity. If someone is serious about buying the largest parts, they are able to get the software on a trial basis, regardless. Austin Tommy Thorn wrote: > John_H wrote: >> What was "teased" in the webcast and not followed up was a new board on the >> horizon using the largest Spartan 3E: the XC3S1600E. > .... >> There are lots of wants among the people who visit the newsgroup regularly. > > With all the competition going on between A and X, I'd like to see more > movement in the category "Largest FPGA with free tool support". A, > with the Cyclone II EP2C70 has been the leader for a very long time > now. X only offers the Spartan 3E XC3S1600E is less than half the size > of the EP2C70. > > One can only hope that X jumps on the opportunity with Virtex 5. > > Tommy >Article: 103911
Vivek Menon wrote: > Hi Duane, > 1. The reference design is power PC based and includes the BERT test. I > do not want to use that. So I thought of using the Rocket I/O > implementation on the logic fabric. Also I am using the fibre optic > cable. What specs to use for that? Fibre Channel is a protocol, and a rather complicated one at that (and it does not necessarily require fiber optic cables). A fiber optic cable can use any protocol you want. Aurora defines it's own protocol, which is a very simple one suited for basic data transfer. It sounds like that is what you want to do. > 2. The ucf file that comes with the Avnet board is for the EDK project. > I am confused about converting it for ISE project. The Avnet ucf file has the pinouts used on the board, and that is not dependent on whether it is an ISE or EDK project. You can copy those pinouts to your own project ucf file, changing the signal names to whatever you intend to use.Article: 103912
Hello Duane, thanks for the reply. What I meant was that the constraints for clocks can be used for the ISE file. However I get errors while trying to define : INST GT_FIBRE_CHAN_INST/mgt_io/mgt_io_1 AREA_GROUP="BERT_0_GRP"; AREA_GROUP "BERT_0_GRP" RANGE=SLICE_X0Y0:SLICE_X33Y59; #---------------------------------------------------------------- # MGT Placement: #---------------------------------------------------------------- #Top MGTs INST GT_FIBRE_CHAN_INST LOC = GT_X1Y1; ## MGT6 Any information on this? Thanks, Vivek Duane Clark wrote: > Vivek Menon wrote: > > Hi Duane, > > 1. The reference design is power PC based and includes the BERT test. I > > do not want to use that. So I thought of using the Rocket I/O > > implementation on the logic fabric. Also I am using the fibre optic > > cable. What specs to use for that? > > Fibre Channel is a protocol, and a rather complicated one at that (and > it does not necessarily require fiber optic cables). A fiber optic cable > can use any protocol you want. Aurora defines it's own protocol, which > is a very simple one suited for basic data transfer. It sounds like that > is what you want to do. > > > 2. The ucf file that comes with the Avnet board is for the EDK project. > > I am confused about converting it for ISE project. > > The Avnet ucf file has the pinouts used on the board, and that is not > dependent on whether it is an ISE or EDK project. You can copy those > pinouts to your own project ucf file, changing the signal names to > whatever you intend to use.Article: 103913
Hi Austin > It is extremely unusual for someone who wishes to use the largest part > to care about free software. That's a blanket assertion that I don't buy at all. > I believe this category might be re-labeled: "fastest way to throw money > away." Make no mistake, Xilinx is a business, not a charity. Sure, but with that argument why offer free tools at all? Obviously, the reason is strategic. Where the line is drawn is probably a judgement call, but at least one competitor disagrees with you of where that is. > If someone is serious about buying the largest parts, they are able to > get the software on a trial basis, regardless. I have done that on occation, but it's a suboptimal solution as I now have a time bomb after which I can't continue developing, I can't share the design, and the development is now constrained to one host. Well, one can only wish :-) TommyArticle: 103914
How does it cost Xilinx money to add larger parts to the free, no support, version of the tools? Especially if you are willing to "loan" out the tools to customers at no cost, adding larger parts to the free tools would not cost you any lost sales either. One area where you may be losing out on chip revenue is when a development board is sold where the customer wants to develop his own FPGA design as part of a larger product. I used to sell DSP boards with an FPGA to provide IO support to the DSP. I had a *lot* of enquiries about programming special apps into the FPGA and could I offer a larger part on the board. This was not part of my business plan since the tools can get expensive for the customer and I did not want to be in that loop. So some boards sales (and FGPA sales) were missed because of lack of support in the Webpack tools for the larger chips. Austin Lesea wrote: > Tommy, > > It is extremely unusual for someone who wishes to use the largest part > to care about free software. > > I believe this category might be re-labeled: "fastest way to throw money > away." Make no mistake, Xilinx is a business, not a charity. > > If someone is serious about buying the largest parts, they are able to > get the software on a trial basis, regardless. > > Austin > > Tommy Thorn wrote: > > John_H wrote: > >> What was "teased" in the webcast and not followed up was a new board on the > >> horizon using the largest Spartan 3E: the XC3S1600E. > > .... > >> There are lots of wants among the people who visit the newsgroup regularly. > > > > With all the competition going on between A and X, I'd like to see more > > movement in the category "Largest FPGA with free tool support". A, > > with the Cyclone II EP2C70 has been the leader for a very long time > > now. X only offers the Spartan 3E XC3S1600E is less than half the size > > of the EP2C70. > > > > One can only hope that X jumps on the opportunity with Virtex 5. > > > > Tommy > >Article: 103915
Is LVTTL or LVCMOS can be used for PCI Signaling? BTW, I'm using Atera MAX-II EPM1270T144C5... - kai -Article: 103916
On Wed, 14 Jun 2006 10:55:10 -0700, Austin Lesea <austin@xilinx.com> wrote: >Tommy, > >It is extremely unusual for someone who wishes to use the largest part >to care about free software. > Austin, I think you misunderstand. The post was about "largest part WITH free tool support". According to the op, now A seems to be winning this contest and he wanted to see if X would up the ante. You're right, I don't think anyone is asking for LX200 to be supported by free tools but something larger than S3E 1600. How about it?Article: 103917
Austin Lesea wrote: > Tommy, > > It is extremely unusual for someone who wishes to use the largest part > to care about free software. Yes, but that is not actually what Tommy was asking. He was not asking for the largest devices to be free, just a nudge in the line - and that line has always been moving anyway, so what we are _really_ talking about, is when? not if? > > I believe this category might be re-labeled: "fastest way to throw money > away." Make no mistake, Xilinx is a business, not a charity. > > If someone is serious about buying the largest parts, they are able to > get the software on a trial basis, regardless. What you've completely missed here, is that users often use MORE than one target device. They might develop with a larger device/demo board, and then port to a final design. Now, a bean counter might just see that as an opportunity : If you get your customers able to use larger parts, they might just find one day, that the ported design can no longer fit in the smaller device, and voila, more revenue :) - and what did that really cost Xilinx ? That same bean counter could map sales of devices, against Tool Ceiling, and that _would_ be interesting data.... -jgArticle: 103918
Vivek Menon wrote: > Hello Duane, > thanks for the reply. What I meant was that the constraints for clocks > can be used for the ISE file. However I get errors while trying to > define : > > INST GT_FIBRE_CHAN_INST/mgt_io/mgt_io_1 AREA_GROUP="BERT_0_GRP"; > AREA_GROUP "BERT_0_GRP" RANGE=SLICE_X0Y0:SLICE_X33Y59; > #---------------------------------------------------------------- > # MGT Placement: > #---------------------------------------------------------------- > > #Top MGTs > INST GT_FIBRE_CHAN_INST LOC = GT_X1Y1; ## MGT6 > > Any information on this? When you sign up with Xilinx for the Aurora core, you will receive a license to use in Coregen to generate a core. When you generate the core, along with the design files, a constraints file will be generated that has all those constraints. You will copy those constraints into your ucf file. The core comes with docs explaining how to use it. I'll admit that the first time you use coregen to generate an Aurora core, it can be tricky trying to figure out what to enter, so you can ask here if you have questions about that part.Article: 103919
rickman wrote:
> Ed McGettigan wrote:
>> Marco wrote:
>>> Hi,
>>> on my AD Spartan3 board I have 3 jumpers selecting the boot mode M0-2.
>>> They let you connect each pin to GND, so if you place no jumper on a
>>> ceretain pin think you get a high signal ('1') on that mode pin. Why?
>>> I was supposed to have internal pullups only on the I/Os, enabled
>>> during the configuration stage by the HSWAP_EN and not also on those
>>> M0-2 pins.
>>> In my board should I do it the same way or shoud I consider a connector
>>> in which jumpers could link those pins to Vcc for '1' or to GND for
>>> '0'?
>>> Thanks,
>>> Marco
>>>
>> All Xilinx devices have weak (10kohm+)internal pullups on the
>> configuration mode select pins. The HSWAP_EN pin only enables/disable
>> the pullup on the non-dedicated pins during configuration.
>>
>> If you do not connect this pin to anything else on the PCB that might
>> cause a current drain (like an LED) you do not need to add a dedicate
>> pullup resistor.
>>
>> Ed McGettigan
>> --
>> Xilinx Inc.
>
> Funny a Xilinx rep would make such a mistake. Yes, these parts have an
> internal pullup on the Mode pins, but it is nowhere near 10K ohms. The
> data sheet specs it at between 1 and 3 kohms and on our board it is
> measuring about 1 kohms. This is significant if you use pulldown
> resistors thinking the pullup is very light. Using a 1 kohm pulldown
> is often used when the internal pullup is 10k or more. But with the
> Spartan 3 parts you need a resistor of 330 ohms or less to be sure you
> pull down hard enough. Of course using jumpers will do the job. I
> just wanted to clarify the 10 kohm mistake since this has caused grief
> with engineers who did not read the data sheet in enough detail
> themselves and relied on advice like Ed (and my FAE) gave.
Rick is correct and I made a mistake. My statement of 10K+ was too generic
and is not accurate for the Spartan-III families. For Virtex-4 and Virtex-5
the minimum value is 16.5K ohm with a typical of 60K ohm. However for the
Spartan-III family our spec has a low of 1.2K ohm and 2.4K ohm for the
Spartan-IIIe family.
Ed McGettigan
--
Xilinx Inc.
Article: 103920backhus wrote: > Hi, > you are trying to synthesize a model that is only useful (and > meaningful) for simulation. > > For a deeper explanation of assigning the null-statement to a signal you > better ask the guys at comp.lang.vhdl. > > The synthesis tools ignore the after Statements, but can't ignore a > missing assignment to signal b, so you get an error. > > What value should be assigned to b when en ='0' ? > "null" is nothing physical, it can either be '0','1' or 'Z'. > So my best guess is : > > architecture behaviour of buffer_32 is > begin > b_driver: process (en, a) > begin > if en = '1' then > b <= a ; > else > b <= (others=>'Z'); -- b may be a vector > end if; > end process b_driver; > end behaviour; > > Have a nice synthesis > Eilert > > nomalus schrieb: > > Got a quick newbee question. I'm using some source files from the VHDL > > cookbook which describe a simple CPU. Many of the files use null > > waveform elements: > > > > architecture behaviour of buffer_32 is > > begin > > b_driver: process (en, a) > > begin > > if en = '1' then > > b <= a after Tpd; > > else > > b <= null after Tpd; > > end if; > > end process b_driver; > > end behaviour; > > > > This analyzes fine with GHDL, but when I try to synthesize this using > > the Xilinx webpack, I get the following error: > > > > Line 63. null waveform element is not supported. > > > > Anyone know of a workaround for this? > > > > Thanks in advance > > I've never seen "null" assigned before. If you want to assign a value to "b" but you don't care what the value is, then use "X", as in: if en = '1' then b <= a; else b <= 'X'; --note this could also be: b <= '-'; end if; HTH -Dave PollumArticle: 103921
Tommy Thorn <tommy.thorn@gmail.com> wrote: >John_H wrote: >> What was "teased" in the webcast and not followed up was a new board on the >> horizon using the largest Spartan 3E: the XC3S1600E. >.... >> There are lots of wants among the people who visit the newsgroup regularly. >With all the competition going on between A and X, I'd like to see more >movement in the category "Largest FPGA with free tool support". A, >with the Cyclone II EP2C70 has been the leader for a very long time >now. X only offers the Spartan 3E XC3S1600E is less than half the size >of the EP2C70. >One can only hope that X jumps on the opportunity with Virtex 5. Seems Actel have started to move in this arena aswell with their A3P series chips at least (like A3P1000-PQ208). They got win32 + linux tools for free from what they told me. That adds another competitor to the Xilinx-Altera pool. Ofcourse Altera have no free linux tool however.. ;)Article: 103922
Has anyone else seen problems with changes to the
latest Xilinx 8.1 Unisim libraries?
I loaded up 8.1sp3 to do some S3E test code; structural code
that worked fine with 6.x now chokes XST because the newer
Unisim library lacks the default values needed to use 'open' on
unused primitive inputs. ( e.g. BUFGMUX with only I1 in use )
Replacing all the "open"s with '0' works at the expense of a routed
'0' net running around the chip.
Short of manually editing the Unisim library, or declaring all the
primitives myself, anyone know of another workaround?
Brian
6.3 unisim_vcomp.vhd BUFGMUX declaration:
component BUFGMUX
port
(
O : out std_ulogic := '0';
I0 : in std_ulogic := '0';
I1 : in std_ulogic := '0';
S : in std_ulogic := '0'
);
end component;
8.1 unisim_vcomp.vhd BUFGMUX declaration:
component BUFGMUX
port
(
O : out std_ulogic;
I0 : in std_ulogic;
I1 : in std_ulogic;
S : in std_ulogic
);
end component;
Article: 103923Hi all, I implemented a bidirectional bus using tristate buffer inside a XPLA3 device. The CPLD is interconnected to an external device by this bidirectional bus. The problem is that I cannot write or read the contents of external device. The timing is correct, I have a doubt: could be possible that the external device has no such output current to drive a low on the bus when the bidirectional bus inside the CPLD is in read direction? Someone know issue about implementation of bidirectional bus using XPL3 device? Thanks, MarocArticle: 103924
Hi Mike, what do you mean with winner? Lowest overall FF count? Sure, but there was never a doubt about it. The question was if a state minimzation can be performed with ISE regardless of the encoding style. The Quartus results are quite interesting. In pseudo_states.pdf we can see the states before(!) minimization. From the autogenerated diagram it's kind of hard to see that the states build a decision tree. (Well... tools :-) ) It's funny to see that S7 and S11 are in double circles unlike the other States above S6. The only difference between the double circled states and the single circled states is, that Y remains constantly '0'. The ptd-fsm checks a serial bitstream X for non-BCD tetrades with LSB first (at S0) and MSB last (at S(>6)), setting the output Y at that moment. Now what happens in the QUARTUS created FSM when it should branch to S7 or S11. Does it remain in S3 or S5 for 2 clock cycles? How? Or has it really kicked away these states, thus running out of synchronization with the data stream. (I doubt, but who knows.) May be it goes over states S8 or S12 and does a tricky output decoding. At least it does some minimization, even if it wasn't expected that way. Thank you for presenting these results. Best regards Eilert Mike Treseler schrieb: > backhus wrote: > >> Mike, interesting result from Quartus. At least it seems to do some >> optimization. > > It may be of academic interest, > but binary encoding is the clear winner here, > as it usually is in small cases. > Even in large cases the difference is > mostly one of speed, not area. > >> Is there anything in the synthesis report that gives information about >> what exactly was done to the FSM? > > looks like it pitched 7 and 11: > http://home.comcast.net/~mike_treseler/pseudo.pdf > http://home.comcast.net/~mike_treseler/pseudo_states.pdf > > -- Mike Treseler
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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