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
Hi,
Chua Kah Hean wrote:
>>-------
>>function hex10
>> ( hex12 : std_logic_vector(11 downto 0))
>>return std_logic_vector is
>>begin
>> return hex12(9 downto 0);
>>end hex10;
>>-------
>>
>>and use:
>>
>>slv(9 downto 0) <= hex10(X"3AC");
>>
>
> Hi all experts out there,
>
> I remember having a problem with the case statement when using this
> approach. For example, the case statement below will not compile
> because hex10(X"3AC") is not locally static. I think even if we make
> hex10 a pure function taking in constants only, we only make it
> globally static only, still not acceptable to the case statement.
> Does anybody have a solution to this? Thanks in advance.
>
> case addr is
> when hex10(X"3AC") => REG_3AC <= edi;
> when others => null;
> end case;
>
How about using integers:
case to_integer(unsigned(addr)) is
when 16#3ac# => ...;
when others => null;
end case;
--
Edwin
Article: 36576Nothing like lack of backward compatibility. We just upgraded to Foundation 4.1i. Now I'm finding the new S/W won't read any of my files created in 2.1i. Is there are file conversion/import utility? Or am I missing a trick? We need to get the files migrated to 4.1i ASAP because I need to modify several of them as I speak. Thanks for any suggestions. Alex Rast arast@inficom.com arast@qwest.netArticle: 36577
Hello We are trying to do a hardware implementation of JPEG2000 to be used for at least 15fps video. From the algorithm, it looks to us like a hardware/software co-design seems more feasilble than a pure hardware implementation. Any thoughts on this? We are also thinking of using a Virtex-II FPGA as a prototyping platform perhaps with an embedded processor. Other options we are investigating are Altera and Actel FPGAs but we would be happy for your advice on this subject. Many thanks Marianne. -- Altek Technologies Ltd. East Sussex Advanced Technology Hub Ashdown House Brighton BN1 9RT tel. +44 (0)1273 877703Article: 36578
ndeshmukh@yahoo.com (nitin) writes: > well i suppose the floor planning of the slices within a CLB is > driven by the fact that they were going to have two carry chains > through it... so they put two this side & two that side... other wise > why not all four in a column...? Because the aspect ration of the CLBs would get problematic. XC3000 and XC4000 have 2x1 LUTs/CLB XC5200 has 4x1 LUTs/CLB Virtex has 2x2 LUTs/CLB Virtex-2 has 4x2 LUTs/CLB Having a "square" was obviously considered better in Virtex. And 4x2 is the nearest possible with 8 LUTs/CLB. Do not forget that having "high" CLBs with 8x1 ratio would result in less dense horizontal wiring, or require wider (and so asymmetrical) wiring bundles in horizontal direction. Alteras FLEX chips actually do this so (8x1 or 10x1), because they are adapted CPLD designs (with the product term array replaced by PIPs and the ORs replaced by LUTs). OTOH Atmel has 1x1 CLBs. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Intellectual Property is Intellectual RobberyArticle: 36579
<Big Snip> All, Has anyone thought of setting up a specific group for this. Seems there is loads of interest but no coordination. I'm interested too Dave (via comp.arch.fpga)Article: 36580
Russell Shaw wrote: > > When the state machine enters state 2 and gets to <1>, then > ptr_en<='1'. Can i assume the counter at <2> will be clocked > in advance of ptr_en being tested at <3> ? I don't know > what to assume about the closeness of timing between the > counter clock <2>, and the state machine clock <4>. First things first: look at what happens when you see a rising edge of the clock. The following all happen simultaneously (to split an infinitive): a) the value of state gets updated from next_state; and b) the counter process tests the reset and enable signals and updates the counter if necessary. The first assignment is easy -- the value of next_state is essentially copied to state. Think about the second. The ONLY thing you (or rather, your process) care about is the *state of all the signals that affect the outcome _AT THE RISING EDGE OF THE CLOCK._* So, at the rising edge of the clock, one of three things will happen: 1) ptr is zeroed. 2) ptr is incremented. 3) ptr remains untouched. Now, to your state machine. The state machine process is only triggered when there's a change on either state or ptr. Now, since both state and ptr both change with the clock, they take on their new values after the clock changes. Therefore, the assignments to ptr_reset and ptr_enable take place AFTER state and ptr change, so the new values of ptr_reset and ptr_enable won't affect state and ptr until the NEXT clock edge. This is Delta Delays 101. Now, if *I* were writing this code, which is not what you asked, I'd write it as a one-process (clocked) state machine, because I find it to be less ambigious at first blush. > Is there a way of keeping the clocks closely aligned? How > do you specify to use a global clock path from within > vhdl code? (i'm using leonardo) You can assume that your synthesis tool will put all clocks on global low-skew clock nets unless a) you tell it to do otherwise, or b) your design has more clocks than global low-skew clock buffers. --a > TIA > > library ieee; > use ieee.numeric_bit.all; > > entity host is > port( > reset: in bit; > clk: in bit); > end host; > > architecture arch of host is > > subtype stype is integer range 0 to 2; > signal state,next_state: stype; > > signal ptr_reset,ptr_en: bit; > signal ptr: integer range 0 to 16; > > begin > > ptr_cntr: > process > begin > <2> wait until clk'event and clk='1'; > if ptr_reset='1' > then > ptr<=0; > <3> elsif ptr_en='1' > then > ptr<=ptr+1; > end if; > end process; > > host_proc: > process(state,ptr) > begin > report "Ans= " & integer'image(ptr); > case state is > when 0=> > ptr_reset<='1'; -- reset ptr > ptr_en<='0'; > next_state<=1; > when 1=> > ptr_reset<='0'; > ptr_en<='0'; > next_state<=2; > when 2=> > if ptr<16 > then > <1> ptr_en<='1'; -- inc ptr > next_state<=1; > else > next_state<=0; > end if; > end case; > end process; > > > state_proc: > process(reset,clk,next_state) > begin > if reset='1' > then > state<=0; > <4> elsif clk'event and clk='1' > then > state<=next_state; > end if; > end process; > > end arch;Article: 36581
Russell Shaw wrote: > > Hi all, > > I've got funny problems of code like this not working well > in the chip (acex 1k30 with 5MHz clock). Consider adding some outputs to your entity to avoid a null synthesis. Consider doing simulation before synthesis. By single stepping through a testbench, you can answer all of your own questions. > Is there a way of keeping the clocks closely aligned? Make sure you use one of the dedicated global clock/reset pins for your clock. > How > do you specify to use a global clock path from within > vhdl code? (i'm using leonardo) I prefer to keep vhdl code free of pin assignments. Let the place and route pick the pins and then edit the resulting assignment file. --Mike TreselerArticle: 36582
What is the advantages/disadvantages of using a CASE statement or an if statement? For example, if I have 10 arrays of 10 integers (array0, array1,...) and I want to sequentially output each array I can either use a CASE statment or a 10 separate IF statements. e.g. if (counter = 0) then ... end if if (counter = 1) then ... end if What I have seen is the clk is slower in a CASE statement than an IF statement because the counter has a huge fanout. any advice or comments? thanks SWArticle: 36583
Samuel Bogale wrote: > > Can someone suggest ideas what FPGA can be used for? Um, vending machines, traffic-light controllers, pizza-delivery route optimizers... --aArticle: 36584
You could just get them off the shelf at http://www.xilinx.com/ipcenter/fec_index.htm srinas wrote: > Dear All, > I have to implement a Reed Solomon Encoder and a convolutional > Interleaver. > Could anybody send me some examples for a (208,188)or DVB standard RS > coder (only the encoder) and the Interleaver. > > Note: > The link > http://www.fokus.gmd.de/research/cc/mobra/products/fec/content.html > > is unavailable now. > Does anybody know where it is know? > > ThanksArticle: 36585
Dean, Try using the push-button reset (perhaps through some debouncing) to pull the FPGA INIT# line low, which will start the FPGA configuration process. If the CPLD's FPGA-configuration logic is essentially isolated from the rest of the CPLD logic, you won't need another reset signal. When I did an FPGA-configurator-in-a-9536, it was a state machine that idled when done (or in event of configuration failure). In that mode, it would wait for the FPGA to tell it that it wanted to be configured. --a Dean Armstrong wrote: > > Hi All, > > I am designing a system which contains a Xilinx XC95288XL CPLD. > > This CPLD has two functions. It must act as an FPGA loader, reading an > FPGA image from ROM and writing it to a Xilinx Spartan II. The second > function is for it to act as an I/O device for the Spartan (which is > configured as a CPU). It is always in only one of these two modes. > > There are two possible reset levels on the board. > > A hard reset (equivalent to power cycling the board, but also possible > via a button) should cause the CPLD to configure the Spartan II. > > A CPU reset (normal reset button) should cause the CPLDs I/O mode to > reset itself (clear status and control registers). > > I would like to know if this is possible to do using the XC95288XL. > On this chip there is only one GSR input. I would probably use this for > the board reset input. Can I use a normal I/O pin for the second reset > signal? > > Thanks very much, > Dean ArmstrongArticle: 36586
Jens-Christian Lache wrote: > I'm not sure if I understood the question right. According to > ds_001_4.pdf > these pins are I/O pins, so there is no reason why not to use them. Well, it complicates whatever non-startup logic is connected to 'em. I always leave the configuration/dedicated pins alone. Saves lotsa headaches later. -aArticle: 36587
Marty wrote: > > I am working on a waveform generator that gets data from a dual-port RAM, > and outputs it. It also has timing and jump instructions in the RAM data. > The goal is to run at 50 MHz. The RAM, is 64K deep, and 15 nS access time. > > I can get the machine to simulate at 33 MHz, but not at 50 MHz. I think the > way to solve this is to redesign the machine in a pipelined form. > I have fit the non pipelined design into an Altera 7512AE. > Some of the problems are getting the machine to do relative jumps - absolute > jumps work. I just finished a waveform generator design, with single-port sync SRAM storing the pattern and jump information. It's pipelined, too. Relative jumps require an adder, which probably wants a clock tick to compute a sum. But you already have an adder if you've got an incrementing counter for your address. Normal operations add 1 to the current address, relative jumps add some (possibly read from RAM) offset to the current address, absolute jumps reload the address counter. Consider that you're using a flow-through type sync SRAM. On clock tick 1, an address is registered. On clock tick two, your data appears on the outputs. (If you use pipelined SRAM, the data will appear with the *second* clock after the address is registered.) The trick to running fast is to make sure you can compute a new address every clock tick. You can also "hold" things by deasserted the SRAM CKE# signal. There's other games you can play, too. > Does anyone know of any tools to help visualize or design a project like this? Pencil and paper (as well as ModelSim) worked for me .... --aArticle: 36588
Jim, Thanks! You're the first one to actually admit to having them IN hand! What package are you using? Regards, Austin "Jim Bittman" <jmbj@bittware.com> wrote in message news:3BF00EF0.62AC256A@bittware.com... > We've been using 10's of 2V1000's (XC2V1000-4FG), and have had no > trouble with deliveries, and the prices have even been coming down! > > We recently asked about some 2V3000's and I think the quote was quite > reasonable with respect to price and delivery. > > Austin Lesea wrote: > > > Austin F, > > > > As in shipments of parts? > > > > 2V40, 2V1000, 2V3000, 2V4000, 2V6000 .... > > > > Maybe someone didn't get their order in on time? > > > > Austin L > > > > -- > ******************************************************************** > * Jim Bittman * Tel: 603-226-0404 * > * BittWare, Inc. * Fax: 603-226-6667 * > * 33 North Main Street * E-Mail: jmbj@bittware.com * > * Concord, NH 03301 * WWW: http://www.bittware.com * > ******************************************************************** > >Article: 36589
Thomas Stanka wrote: > > Hi all, > > Russell Shaw <rjshaw@iprimus.com.au> wrote: > > > Is there a way of keeping the clocks closely aligned? How > > do you specify to use a global clock path from within > > see below > > [..] > > <2> wait until clk'event and clk='1'; > > I wouldn't use this in synthesizeable code. > This is eqivalent to process(Clk) and leed to synchronous FF. From what i've seen, its quite valid for synthesizeable code. Its in Bhasker: A VHDL Synthesis Primer, and in the leonardo synthesis manual. > [..] > > when 2=> > > if ptr<16 > > then > > <1> ptr_en<='1'; -- inc ptr > > next_state<=1; > > This is a Mealy description in a mainly Moore automate. First place to get > problems, but should do in this case.. > > > state_proc: > > process(reset,clk,next_state) > > This is your problem. > If you want to sysnthesize your code, you've got two [1] kinds of proces: > one for Logik and one for Register. If you want to get Register, your > process should be sensitive to Clk and Reset, if you want to get logik, you > should be sensitive to every signal that effects the signals changed during > the process. Mixing both styles like your process creates latches. But with synthesis, i think *everything* that gets assigned a value within a process, has to be in the sensitivity list or leonardo gives warnings. Only with a "wait until" line, does the process not have a sensitivity list. > Your code mixes synch. FF and asynch Latches (I wonder, that you get no > errors or warnings during synthesis) something you should use _very_ > carefully. The latches should just hold ptr_en and ptr_reset, because they're not assigned in every case option. > [1] actually two an a half, because sometimes you want Latches.Article: 36590
Andy Peters wrote: > > Russell Shaw wrote: > > > > When the state machine enters state 2 and gets to <1>, then > > ptr_en<='1'. Can i assume the counter at <2> will be clocked > > in advance of ptr_en being tested at <3> ? I don't know > > what to assume about the closeness of timing between the > > counter clock <2>, and the state machine clock <4>. > > First things first: look at what happens when you see a rising edge of > the clock. The following all happen simultaneously (to split an infinitive): > > a) the value of state gets updated from next_state; and > b) the counter process tests the reset and enable signals and updates > the counter if necessary. > > The first assignment is easy -- the value of next_state is essentially > copied to state. > > Think about the second. The ONLY thing you (or rather, your process) > care about is the *state of all the signals that affect the outcome _AT > THE RISING EDGE OF THE CLOCK._* So, at the rising edge of the clock, > one of three things will happen: > > 1) ptr is zeroed. > 2) ptr is incremented. > 3) ptr remains untouched. > > Now, to your state machine. The state machine process is only triggered > when there's a change on either state or ptr. Now, since both state and > ptr both change with the clock, they take on their new values after the > clock changes. Therefore, the assignments to ptr_reset and ptr_enable > take place AFTER state and ptr change, so the new values of ptr_reset > and ptr_enable won't affect state and ptr until the NEXT clock edge. agree with all of above. > This is Delta Delays 101. > > Now, if *I* were writing this code, which is not what you asked, I'd > write it as a one-process (clocked) state machine, because I find it to > be less ambigious at first blush. I did that the first few times, but it wasn't clear how the code would be synthesized when having numbers incremented inside of case statements. > > Is there a way of keeping the clocks closely aligned? How > > do you specify to use a global clock path from within > > vhdl code? (i'm using leonardo) > > You can assume that your synthesis tool will put all clocks on global > low-skew clock nets unless a) you tell it to do otherwise, or b) your > design has more clocks than global low-skew clock buffers.Article: 36591
Mike Treseler wrote: > > Russell Shaw wrote: > > > > Hi all, > > > > I've got funny problems of code like this not working well > > in the chip (acex 1k30 with 5MHz clock). > > Consider adding some outputs to your entity > to avoid a null synthesis. > > Consider doing simulation before synthesis. > > By single stepping through a testbench, you > can answer all of your own questions. Well, i did simulation to see why it wouldn't work (the code in the original posting), but it did work. > > Is there a way of keeping the clocks closely aligned? > > Make sure you use one of the dedicated global > clock/reset pins for your clock. I'll try...Article: 36592
It should be easy to verify if your board will be ok. Just remove the caps around one chip, power-up, and look at glitch levels on the pins/pads with a high-speed cro (you'll need to have a good ground-pin on the cro probe). If the glitching is less than 10% of VCC, or adding the caps makes little difference, the caps aren't really needed. Its important that the power-ground planes are large in area, and adjacent (higher capacitance, lower pulse impedance). Standard 2/4-layer board probably wouldn't be good enough. Austin Lesea wrote: > > Russell, > > You must enjoy dangerous living .... > > And, the inductance of the flip chip packages is 5 to 8 times less than that of > the wire bonded packages as there are no wires, just hundreds and hundreds of tiny > solder balls over the entire top surface of the die connecting to ground and > Vcc's. > > Austin > > Russell Shaw wrote: > > > pete dudley wrote: > > > > > > Our bread and butter decoupling cap is .01uF (10nF) 0805 surface mount, like > > > 1 per 4 VCC on fpga's, and we back them up with a few larger caps up to 10uF > > > tantalums... > > > > > > We use terminated differential signalling for the high speed stuff if > > > possible to cancel the ground bounce and use slew rate control on the rest. > > > > > > On the highest end of the switching spectrum the ground/power planes help > > > you and my guess is that 100pF or smaller chip caps do nothing for you. > > > > > > Once we built some multiprocessor boards that ran about 150MHz but the caps > > > were bad so we removed all of them. The boards ran fine without any > > > decoupling. I'd like to try that experiment again with high speed fpga's. > > > > > > I like Austin's idea of tuning the caps to the operating frequency. > > > > With *thin* layers (such as in 8 layer boards etc), all the caps > > can be left off except one electro per board. The VCC and GND planes > > must be adjacent to provide very low planar transmission line > > impedance (lumped capacitance is meaningless at fast edges). > > > > A bit of track to bypass caps and vias hardly matters relative > > to the inductance in many internal bond wires.Article: 36593
Nial Stewart wrote: > > However, i > > think there might be a clock-alignment problem somewhere. > > There shouldn't be. If you've used a global clock input pin > for your clock they guarantee set up and hold times from > egister to register. it's then just a matter or making > sure you're writing good synchronous code. Actually, i was using the global clock pin for a 20MHz clock, then the 5MHz clock i used for everything comes from a vhdl x4 counter, so i'll need to check that clock routing.Article: 36594
Sul Weh wrote: > > What is the advantages/disadvantages of using a CASE statement or an if > statement? > For example, if I have 10 arrays of 10 integers (array0, array1,...) and I > want to sequentially output each array I can either use a CASE statment or a > 10 separate IF statements. > e.g. if (counter = 0) then ... end if > if (counter = 1) then ... end if > > What I have seen is the clk is slower in a CASE statement than an IF > statement because the counter has a huge fanout. > > any advice or comments? I'd do it this way (less code): Declare an array of 10 items with 10-bit integers, and initialize them. The synthesizer should see this hard-coding, and make a small rom. Now all you need to do is have a counter index the pointer of this array: output_sig<=array_of_int(cntr);Article: 36595
Hi, I'm using a Spartan II-50-5 with Base Express 3.3.08i. I have a design where a main state machine sends out clock enables to registers in other areas. A data path I have between two sets of registers contains combinatorial logic that takes ~17ns to complete. My clock is 9ns. Since I control when the clock enables happen in the main state machine, I know I have plenty of time to let that path chug. How do I convey this information to the Xilinx tools? The par comes back saying that the 9ns clock can't be met because of these extra long paths. I'd rather not pipeline the logic because that would use up a lot of FF's, which are already getting scarce. Bigger/faster parts are also out due to cost. Thanks for any ideas or pointers, gArticle: 36596
Yes, but if I have *10* roms, each each 10 integers in them then it would be if (cntr2 = 0) then output_sig <= array_of_int0(cntr) so I have 10 arrays of 10 integers "Russell Shaw" <rjshaw@iprimus.com.au> wrote in message news:3BF06C0F.32B632D2@iprimus.com.au... > > > Sul Weh wrote: > > > > What is the advantages/disadvantages of using a CASE statement or an if > > statement? > > For example, if I have 10 arrays of 10 integers (array0, array1,...) and I > > want to sequentially output each array I can either use a CASE statment or a > > 10 separate IF statements. > > e.g. if (counter = 0) then ... end if > > if (counter = 1) then ... end if > > > > What I have seen is the clk is slower in a CASE statement than an IF > > statement because the counter has a huge fanout. > > > > any advice or comments? > > I'd do it this way (less code): Declare an array of 10 items with 10-bit > integers, and initialize them. The synthesizer should see this > hard-coding, > and make a small rom. Now all you need to do is have a counter index the > pointer of this array: output_sig<=array_of_int(cntr);Article: 36597
You forgot elevator controllers and blackjack machines ;-)
Andy Peters wrote:
> Samuel Bogale wrote:
> >
> > Can someone suggest ideas what FPGA can be used for?
>
> Um, vending machines, traffic-light controllers, pizza-delivery route optimizers...
>
> --a
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 36598And the classical number sequence recognizer. Ray Andraka wrote: > > You forgot elevator controllers and blackjack machines ;-) > > Andy Peters wrote: > > > Samuel Bogale wrote: > > > > > > Can someone suggest ideas what FPGA can be used for? > > > > Um, vending machines, traffic-light controllers, pizza-delivery route optimizers... -- rk Just an OldEngineer The history of engineering is full of examples of dramatic failures that were once considered confident extrapolations of successful designs. -- H. Petroski No extrapolating without a permit. -- rk, circa 1988Article: 36599
> > By single stepping through a testbench, you > > can answer all of your own questions. > > Well, i did simulation to see why it wouldn't work (the code > in the original posting), but it did work. > Your code is perfectly OK and should work in any unit delay simulators. > > > Is there a way of keeping the clocks closely aligned? > > > > Make sure you use one of the dedicated global > > clock/reset pins for your clock. > > I'll try... As Andy.P said in his message, the synthesis tool should add a global clock buffer to your clock tree. The clock skew out of the global buffer is usually very low (within 0.1ns in one Xilinx Virtex FPGA I had used before). I think it is a valid assumption that your logic delays are always longer than the clock skew. I am not sure about acex 1k30 though. My guess is that it should have similar thing. If for any reason, the synthesis tool doesn't pick the global clock buffer for your clock, you can always add a global buffer marco in your code to force the tool to use one. Or try to use a better synthesis tool.
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