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
Hal, I like your line or thought, and I have been thinking along the same lines, without good results. Maybe this community can come up with a simple solution: Use a few external components to adjust the duty cycle, and perhaps also the alternate period problem. For simplicity: accept a relatively low frequency ( <40 MHz). Any takers out there? I can promise publication, fame and glory... Peter Alfke ============================== Hal Murray wrote: > > >If you don't care about the 2f duty cycle, and are also willing to live > >with the affect of uncontrolled incoming duty cycle at f, causing > >alternating period length at 2f, then you can use the circuit described > >in TechXclusives "Six Easy Pieces". > > Assuming the clock is always running and at least in the ballpark of > 50-50 duty cycle... > > Can I fixup the duty cycle with a cap, inverter, and big > feedback/bias resistor? > > If I'm willing to go off-chip and back in, will that work for the > 2F clock? > > [Yes, DLLs/PLLs are good.] > > -- > The suespammers.org mail server is located in California. So are all my > other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited > commercial e-mail to my suespammers.org address or any of my other addresses. > These are my opinions, not necessarily my employer's. I hate spam.Article: 63026
Hi Si, Si wrote: > I am fairly new to Xilinx! > I am looking to implement a System generator (SG) design with a > Microblaze IP! How would one do this as I am a wear Xilinx does not > provide intrinsic support for the PPC405 (V-II Pro) or Microblaze in > SG? try XAPP264 - Building OPB Slave Peripherals using System Generator Regards, JohnArticle: 63027
Hi, > Do you have any suggested parts for the level translators? Unfortunately, I do not. I've been dealing with bus switches because they are bidirectional, which is important for the application I'm dealing with. There are a number of vendors. > I don't really care about the rules just to check off the > boxes. I'm willing to cheat if I can convince myself (and > some friends?) that the total system will work solidly. There are many people in this same situation! > There are two parts to that. One is in limited cases, say > one fewer card on the bus. The other is in any configuration > legal under the specs. We've been looking at the general case, because it is hard for us to control an end user's bus... > How far did you bend the rules? How much testing/Spicing did > you do? The Xilinx XAPP646, XAPP653, and XAPP659 application notes are a good overview of a solutions Xilinx is recommending. These were developed by the Xilinx applications team. I have not done any spice simulations, but I have tested these suggestions in hardware at the PCI Compliance Workshops and have not had any issues. If you are using these bus switches for 5V PCI, the only 5V PCI bus is a 33 MHz, 5V bus. Everything else is 3.3V. In a 33 MHz, 5V bus, our I/O timing has so much slack that the impact of these switches is next to nothing. It is, however NON-COMPLIANT. A possible area of concern is in cases where you are also trying to support other modes, like a Universal 133 MHz PCI-X card. When such a card is in a 33 MHz, 5V slot, the impact is again next to nothing... However, when you put such a design in a 133 MHz PCI-X slot, you don't have as much slack... I have heard a number of people comment on this at the PCI Compliance workshops when they saw what I was testing. I've tested several PCI-X 133 MHz designs using bus switches and have not had any failures. I have also seen (but not personally tested) customers doing 5V designs using bus switches with VirtexE and Spartan-IIE. > Do modern FPGAs have a low enough pin capacitance so that the > added capacitance of something like a QuickSwitch fits the old > rules? Or are they fast enough to go through an honest repeater > type chip so there is only one bus load? They are fairly low delay. > Mostly, I'm just curious. If/when I get enough time, I'd like > to build a hobby priced board that I can plug into something like > PCI. For now, that's old 33 MHz 5V PCI. Spartan-II seems like > the best bet. But the clocking in newer chips is attractive. > If there is a solid way to connect them to old PCI, I'd add that > to my list of chips to consider. I have photoplots for a board that uses the original Virtex at http://www.engr.sjsu.edu/crabill/projects but if you are looking at 33 MHz, 5V as your primary mode of operation, I would think using something newer with bus switches might be more attractive. EricArticle: 63028
"Martin Thompson" wrote: > If you have solid planes (prefereably closely spaced) you don't need > to worry about 'close' in the sense that you probably think of as > close. If you have vias to the planes on *very* short tracks, or even > better in the pad, then the planes will act as a very low impedance > route for your currents. If you think of the time the energy will > take to travel from capacitor to chip, the speed of light on FR4 is > around 2/3c or 2e8 m/s. In 1ns, this is around 20cm. Halve this for > the energy to get back and forth and even 10cm is "close". > > I don't have any pictures to hand, but we've done boards like this > with 100MHz memory interfaces and 150MHz core DSP clocks that work fine. I'll have to disagree with some of this (not meant as criticism, just a point for discussion). The number I use (and see in most books) for propagation in FR4 boards is 140 to 180ps/in for outer traces and about 180ps/in for inner. That would mean about 1.4ns/20cm. Operating at 100MHz with, say, 1ns edges, means that a cap 10cm away would not be able to deliver significant current for the first 0.7ns of the edge, which pretty much hoses you. This is under ideal conditions, ignoring capacitor frequency-dependant characteristics; mounting-related inductance; trace/plane inductance; board/pin interface issues, etc. Because of this and more, I think that 10 to 20cm is far from close (that sounds funny) for high speed design. The characteristics of the caps and the mounting/routing methodology can make this a serious issue. There are interesting threads and authorithative information about this very subject on the signal integrity list. For my last design truly labored over this and took the approach of writing a custom power distribution system simulation tool in order to get a handle on what was going on. Things get serious once you stare down at the prospect of hundreds of pins switching simultaneusly at a given edge rate. And that's what's important, the edge rates, not the frequency. The thinking can be abstracted to using a bunch of caps (the decoupler array) to charge another set of caps (the output traces) through the board-to-chip-to-board interface. If you start looking at the behavior of capacitors as a function of frequency (and, in isolation of board layout/mounting effects) you'll see that the C and L induced self-resonant behavior can play interesting tricks with what a cap can really do. Of course ESR and ESL are frequency depandant themselves, although it is nearly impossible to get this data from manufacturers. Beyond that, I find that the field turns "religious" real fast. There are three basic approaches: 1- Do it the way we've been doing it 'cause it seems to work 2- Use a range of caps to cover the frequency (ehem, edge) range 3- Use only two or three a couple of values to cover the range 4- If it looks good during layout it should work. #1 is folklore and may only have merit if a knowledgeable engineer setup rules conservative rules that can be followed by those working on new designs independently. I find that many think that the old 0.1uF capacitor rules could be adequate for high-speed design when, in reality they are just about useless. The same applies to a certain range of tantalums. So, for my money, option #1 is not a great solution unless you know where it came from, how it got there and what the constraints might be. #2 is promoted by one school of thought within the SI community. It is perfectly valid, of course. However, I don't see it as manufacturing/BOM friendly. The idea of stuffing a board with a dozen different decoupling capacitor values is not something I look forward to from many perspectives. The theory here is that, by being intelligent about the choice of caps, their mounting and routing, you create a very low impedance "bucket" to cover the edge rates for the design. Like I said, valid, but not my cup of tea. #3 is also supported by a sect within the SI community and happens to be what I chose to do. The idea here, loosely speaking, is to form the aforementioned "bucket" with just a few values. The value of the capacitor is not as important as the frequency domain characteristics of the same. This is part of the problem today. Cap manufacturers are begining to be pushed by SI experts to address high-speed decoupling needs and produce (and quantify) caps that are friendlier to this approach. By dividing the spectrum in to low, mid, mid-high and high frequency (edge rate) zones you can select four capacitors (again, not so much values as much as frequency related characteristics) to cover the range. A typical setup will have electrolytics by the power source (LF), medium-packaged tantalums within 5 to 10 cm of relevant chips (MF to HF) and a couple of small-package chip cap flavors within about 2cm of high-speed chips (HF). The significance of speaking in terms of packages as opposed to values is that the package type becomes the primary factor in such properties as ESL (which is the dominant element as frequencies rise). Small tantalums, for example, like 4.7 to 10uF are absolutely worthless for high-speed decoupling designs. You have to get into the larger packages in order to get decent ESR and ESL characteristics. What attracted me to #3, aside from the obvious BOM-friendly results, was the fact that you can engineer a much smoother impedance "bucket". Option #2 requires very careful design, modeling and simulation to ensure that you are not creating a real problem or it can produce weird peaky resonant behavior . I wasn't equipped nor inclined to do that and #3 made more sense overall. What's missing in the decoupling cap world are caps with low ESL and not so low ESR (or quantifiable ESR). If you run the curves, you want some ESR to mitigate peaky resonance effects. Finally, #4, is included in my list because it was something a "professional" PCB designer told me when I was considering using his company's services. The way this person did high-speed layouts was to "make it look good and it will work fine". I would imagine there's a lot of that going on out there. I can only wonder and cringe. To address the OP's questin directly. There are good guidelines out there on what is required and many options on how to do it. Every layout will be different due to things like the which and how many pins you use. You need to get a set of high-speed decouplers very close to the FPGA, within a 2cm circle, I'd say. Modern 0402 components allow you to place a good number of these within the device's footprint. Fan out from there with mid to low frequency caps to support charge transfer and avoid starving he HF caps. Again, quantity and type depend on your design and edge rates. There are good books out there that cover the basics. One such books is "High Speed Digital Design, a Handbook of Black Magic" by Howard Johnson. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 63029
What's the clock frequency for this design? At what rate are the 32 bit words generated? Can you take 32 clocks to produce the desired results? If not, if the frequency of operation is low enough, you could multiply it by 32 and get your results within a clock or two. If none of the above works, you could probably pipeline a solution. During each stage a prioritized decoder would pick off the first "1" and give you a result. At the same time, that "1" would be masked off so that it won't appear in the next stage. Repeat four times and you have your solution. It will probably take four to eight clocks depending on details (don't have my thinking cap fully on). -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 63030
"Martin Euredjian" <0_0_0_0_@pacbell.net> writes: > "Martin Thompson" wrote: > > > If you have solid planes (prefereably closely spaced) you don't need > >to worry about 'close' in the sense that you probably think of as > >close. If you have vias to the planes on *very* short tracks, or even > >better in the pad, then the planes will act as a very low impedance > >route for your currents. If you think of the time the energy will > >take to travel from capacitor to chip, the speed of light on FR4 is > >around 2/3c or 2e8 m/s. In 1ns, this is around 20cm. Halve this for > >the energy to get back and forth and even 10cm is "close". > > > > I don't have any pictures to hand, but we've done boards like this > >with 100MHz memory interfaces and 150MHz core DSP clocks that work > >fine. > > > I'll have to disagree with some of this (not meant as criticism, just > a point for discussion). > Fair enough :-) > The number I use (and see in most books) for propagation in FR4 boards > is 140 to 180ps/in for outer traces and about 180ps/in for inner. 180ps/in makes out to be 180/25.4 ps/mm ~ 7ps/mm (1.4e8 m/s) > That would mean about 1.4ns/20cm. Indeed it would, I think I must have dropped a factor of 10 somewhere, sorry about that! I did the sums properly when I designed the board, honest :-) > Operating at 100MHz with, say, 1ns > edges, means that a cap 10cm away would not be able to deliver > significant current for the first 0.7ns of the edge, which pretty much > hoses you. This is under ideal conditions, ignoring capacitor > frequency-dependant characteristics; mounting-related inductance; > trace/plane inductance; board/pin interface issues, etc. > > Because of this and more, I think that 10 to 20cm is far from close > (that sounds funny) for high speed design. The characteristics of the > caps and the mounting/routing methodology can make this a serious > issue. There are interesting threads and authorithative information > about this very subject on the signal integrity list. > Indeed - that's where I learned a lot of this information from... How about we say that 1-2cm is close enough (for the HF decouplers?) > > For my last design truly labored over this and took the approach of > writing a custom power distribution system simulation tool in order to > get a handle on what was going on. Things get serious once you stare > down at the prospect of hundreds of pins switching simultaneusly at a > given edge rate. And that's what's important, the edge rates, not the > frequency. The thinking can be abstracted to using a bunch of caps > (the decoupler array) to charge another set of caps (the output > traces) through the board-to-chip-to-board interface. > Agreed - I did much the same thing here. > If you start looking at the behavior of capacitors as a function of > frequency (and, in isolation of board layout/mounting effects) you'll > see that the C and L induced self-resonant behavior can play > interesting tricks with what a cap can really do. Of course ESR and > ESL are frequency depandant themselves, although it is nearly > impossible to get this data from manufacturers. > It's getting better, but there wasn't much useful data when I did this either. I ended up distributing lots of different values of capacitor to get a flat impedance profile - which doesn;t half make your BOM long. And makes population a trial. I'm not sure if I'd do this again unless absolutely necessary! > Beyond that, I find that the field turns "religious" real fast. There > are three basic approaches: > > 1- Do it the way we've been doing it 'cause it seems to work 2- Use a > range of caps to cover the frequency (ehem, edge) range 3- Use only > two or three a couple of values to cover the range 4- If it looks good > during layout it should work. > > #1 is folklore and may only have merit if a knowledgeable engineer > setup rules conservative rules that can be followed by those working > on new designs independently. I find that many think that the old > 0.1uF capacitor rules could be adequate for high-speed design when, in > reality they are just about useless. The same applies to a certain > range of tantalums. So, for my money, option #1 is not a great > solution unless you know where it came from, how it got there and what > the constraints might be. > Agreed - the words "conservative rules" are appropriate... even for low-speed designs (are there any of those any more?) you may be spending too much on your caps. > #2 is promoted by one school of thought within the SI community. It > is perfectly valid, of course. However, I don't see it as > manufacturing/BOM friendly. The idea of stuffing a board with a dozen > different decoupling capacitor values is not something I look forward > to from many perspectives. The theory here is that, by being > intelligent about the choice of caps, their mounting and routing, you > create a very low impedance "bucket" to cover the edge rates for the > design. Like I said, valid, but not my cup of tea. > Right, should have read on before scribbling my earlier paragraph :-) > #3 is also supported by a sect within the SI community and happens to > be what I chose to do. The idea here, loosely speaking, is to form > the aforementioned "bucket" with just a few values. The value of the > capacitor is not as important as the frequency domain characteristics > of the same. This is part of the problem today. Cap manufacturers > are begining to be pushed by SI experts to address high-speed > decoupling needs and produce (and quantify) caps that are friendlier > to this approach. > > By dividing the spectrum in to low, mid, mid-high and high frequency > (edge rate) zones you can select four capacitors (again, not so much > values as much as frequency related characteristics) to cover the > range. A typical setup will have electrolytics by the power source > (LF), medium-packaged tantalums within 5 to 10 cm of relevant chips > (MF to HF) and a couple of small-package chip cap flavors within about > 2cm of high-speed chips (HF). The significance of speaking in terms > of packages as opposed to values is that the package type becomes the > primary factor in such properties as ESL (which is the dominant > element as frequencies rise). Small tantalums, for example, like 4.7 > to 10uF are absolutely worthless for high-speed decoupling designs. > You have to get into the larger packages in order to get decent ESR > and ESL characteristics. > I would add that the inductance is affected quite strongly by mounting method (number of vias and the inductance of the copper connecting them to the pads) and by the spreading inductance of the planes. Did you take advantage of thin dielectrics for extra high-quality capacitance? We put two 3.3V/GND 4thou separation pairs in the board, which got us a few nF of very low inductance capacitance, which comes in handy at the top end. I came to the conclusion that above 100-150MHz you couldn't do a lot with capacitors anyway. > What attracted me to #3, aside from the obvious BOM-friendly results, > was the fact that you can engineer a much smoother impedance "bucket". > Option #2 requires very careful design, modeling and simulation to > ensure that you are not creating a real problem or it can produce > weird peaky resonant behavior . I wasn't equipped nor inclined to do > that and #3 made more sense overall. What's missing in the decoupling > cap world are caps with low ESL and not so low ESR (or quantifiable > ESR). If you run the curves, you want some ESR to mitigate peaky > resonance effects. > You could always fit some small resistors in series :-) Looks like we came to the same conclusions in the end then! > Finally, #4, is included in my list because it was something a > "professional" PCB designer told me when I was considering using his > company's services. The way this person did high-speed layouts was to > "make it look good and it will work fine". I would imagine there's a > lot of that going on out there. I can only wonder and cringe. > Frightening. Unless their idea of aesthetically pleasing happens to be trained by what will work .... > > To address the OP's questin directly. There are good guidelines out > there on what is required and many options on how to do it. Every > layout will be different due to things like the which and how many > pins you use. You need to get a set of high-speed decouplers very > close to the FPGA, within a 2cm circle, I'd say. And I'd agree now my 10s are in the right place :-) > Modern 0402 > components allow you to place a good number of these within the > device's footprint. Fan out from there with mid to low frequency caps > to support charge transfer and avoid starving he HF caps. Again, > quantity and type depend on your design and edge rates. There are > good books out there that cover the basics. One such books is "High > Speed Digital Design, a Handbook of Black Magic" by Howard Johnson. > I can recommend that book also, along with subsribing to the si-list (http://www.freelists.org/webpage/si-list) Apologies again for my arithmetic! Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 63031
Hi, when using linker scripts, how can you check if the various sections actually fit into the specified memory regions ? Thanks, TomArticle: 63032
Hi people, can anybody help me?
I want to implement a clock process in a modul to generate a
independent testbench. My gain is to translate the systemc-code to
vhdl and simulate the projekt in vhdl. It is possible to implement
sc_clock outside sc_main(), but i can not use the parameters for
example sc_clock clk("Clk",20 ,0.5,2,true).
Have anybody a similar problem and have you found a solution?
Thanks.
Article: 63033When using Xilinx ISE 4.1 to archive my project I get the following message: ************************ The zip process invoked as zip -r -q [zip_path]\filename.zip [netlist_path] [project_path] failed: *********************** It doesn't give any reason why it's failed. Has anyone else seen this and knows why?Article: 63035
Hi Champs
Its Isaac after long time,,,,,,,,,,,,,,I am having problem reading out
values from SRAM in FPGA everytime I try to target SRAM I am getting
0. The code is given below . The check node and variable node
component's function is not mentioned here.
Can any body pin point the problem....In state s6 I am reading out the
values from FPGA. State s2 and s3 are not defined.
P_IO_FFS : process(
CLK_2X, LOCKED
)
begin
if RISING_EDGE(CLK_2X) then
if LOCKED = '1' then
-- Outputs
-- LED_V3 <= LED_V3_int;
STAT_V3 <= STAT_V3_int;
-- Inputs
SR_ADDR_IO_int <= SR_ADDR_IO;
SR_DATA_IO_int <= SR_DATA_IO;
SR_IRD_int <= SR_IRD;
SR_IWR_int <= SR_IWR;
SR_IVCS_V3_int <= SR_IVCS_V3;
end if;
end if;
end process P_IO_FFS;
Process (CLK_2X,SR_ADDR_IO_int,SR_DATA_IO_int,SR_IWR_int,SR_IVCS_V3_int)
begin
if RISING_EDGE(CLK_2X) then
if SR_IVCS_V3_int = '0' then
if SR_IWR_int = '0' then
SR_DATA_IO_int <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
state_signal <= '0';
if SR_ADDR_IO_int = "000000" then
channelbit1 <= SR_DATA_IO_int(2 downto 0) ;
elsif SR_ADDR_IO_int = "000001" then
channelbit2 <= SR_DATA_IO_int(2 downto 0) ;
elsif SR_ADDR_IO_int = "000010" then
channelbit3 <= SR_DATA_IO_int(2 downto 0) ;
elsif SR_ADDR_IO_int = "000011" then
channelbit4 <= SR_DATA_IO_int(2 downto 0) ;
elsif SR_ADDR_IO_int <= "000100" then
channelbit5 <= SR_DATA_IO_int(2 downto 0) ;
elsif SR_ADDR_IO_int = "000101" then
channelbit6 <= SR_DATA_IO_int(2 downto 0) ;
elsif SR_ADDR_IO_int = "000110" then
channelbit7 <= SR_DATA_IO_int(2 downto 0) ;
elsif SR_ADDR_IO_int = "000111" then
channelbit8 <= SR_DATA_IO_int(2 downto 0) ;
elsif SR_ADDR_IO_int = "001000" then
channelbit9 <= SR_DATA_IO_int(2 downto 0) ;
elsif SR_ADDR_IO_int = "001001" then
channelbit10 <= SR_DATA_IO_int(2 downto 0) ;
elsif SR_ADDR_IO_int = "001010" then
channelbit11 <= SR_DATA_IO_int(2 downto 0) ;
elsif SR_ADDR_IO_int = "001011" then
channelbit12 <= SR_DATA_IO_int(2 downto 0) ;
state_signal <= '1';
end if;
end if;
end if;
end if;
end process ;
process3 : process (CLK_2X,state)
begin
if RISING_EDGE(CLK_2X) then
case state is
when s1 =>
-- if RISING_EDGE(CLK_2X) then
paritycheck <= '0';
if state_signal = '1' then
k <= 0;
state <= s4;
end if;
-- end if;
when s4 =>
-- if RISING_EDGE(CLK_2X) then
k <= k + 1;
state <= s5;
-- end if;
when s5 =>
-- if RISING_EDGE(CLK_2X) then
if remainder = 0 then
k <= 0;
state <= s6 ;
paritycheck <= '1';
eb_bits <= eb_hat_bits;
else
state <= s4 ;
k<= k+1;
end if ;
-- end if;
when s6 =>
-- if RISING_EDGE(CLK_2X) then
if SR_IVCS_V3_int = '0' then
if SR_IRD_int = '0' then
if SR_ADDR_IO_int = "001100" then
SR_DATA_IO (11 downto 0)<= eb_bits;
SR_DATA_IO (31 downto 12) <= "00000000000000000000";
state <= s7;
end if;
else
Null;
end if;
else
Null;
end if ;
-- end if;
when s7 =>
-- if RISING_EDGE(CLK_2X) then
if SR_IVCS_V3_int = '0' then
if SR_IWR_int = '0' then
if SR_ADDR_IO_int = "001101" then
state <= s1;
else Null;end if;
else Null; end if;
else Null; end if;
-- end if;
when others =>
Null;
end case;
end if;
end process process3;
-----------------------------------------------------------------------------------
--Parity Check Process
-- Process (clock)
Process (start,CLK_2X)
begin
if CLK_2X'EVENT and CLK_2X = '1' then
if start = '1' then
address <= address + "001";
data <= eb_hat_bits;
a <= '0';
kk <= '0';
-- t<= '0';
s<= '0';
q<= '0';
elsif start = '0' then
t<= '0';
end if;
if address = "001" then
kk<= '1';
end if;
if address = "010" then
a <= '1' ;
address <= "ZZZ";
end if ;
if a = '1' then
s <= '1';
end if;
if s = '1' then
t <= '1';
address <= "000";
end if;
end if;
end process ;
Process (start,address)
begin
if start = '1' then
case address is
when "000" =>
word1 <= rom( conv_integer("000"));
word2 <= rom( conv_integer("001"));
word3 <= rom( conv_integer("010"));
word4 <= rom( conv_integer("011"));
word5 <= rom( conv_integer("100"));
word6 <= rom( conv_integer("101"));
when others =>
Null;
end case;
end if;
end process ;
Process (a)
begin
if a = '1' then
adderrow1 <= add1 + add2+ add3 + add4 + add5 + add6+add7 + add8+
add9 + add10+add11+add12;
adderrow2 <= adder1_2+adder2_2+adder3_2+adder4_2+adder5_2+adder6_2+
adder7_2+adder8_2+adder9_2+adder10_2+adder11_2+adder12_2;
adderrow3 <= adder1_3+adder2_3+adder3_3+adder4_3+adder5_3+adder6_3+
adder7_3+adder8_3+adder9_3+adder10_3+adder11_3+adder12_3;
adderrow4 <= adder1_4+adder2_4+adder3_4+adder4_4+adder5_4+adder6_4+
adder7_4+adder8_4+adder9_4+adder10_4+adder11_4+adder12_4;
adderrow5 <= adder1_5+adder2_5+adder3_5+adder4_5+adder5_5+adder6_5+
adder7_5+adder8_5+adder9_5+adder10_5+adder11_5+adder12_5;
adderrow6 <= adder1_6+adder2_6+adder3_6+adder4_6+adder5_6+adder6_6+
adder7_6+adder8_6+adder9_6+adder10_6+adder11_6+adder12_6;
else
Null;
end if;
end Process ;
Process (s)
begin
if s = '1' then
-- Addition <= adderrow1 + adderrow2 + adderrow3
-- + adderrow4 + adderrow5 + adderrow6 ;
Remainder1 <= adderrow1 rem 2;
Remainder2 <= adderrow2 rem 2;
Remainder3 <= adderrow3 rem 2;
Remainder4 <= adderrow4 rem 2;
Remainder5 <= adderrow5 rem 2;
Remainder6 <= adderrow6 rem 2;
else
Null;
end if ;
end process ;
Process (t)
begin
if t = '1' then
remainder <= Remainder1 + Remainder2 + Remainder3 + Remainder4
+Remainder5 + Remainder6;
elsif t = '0' then
remainder <= 1;
end if ;
end process ;
state_machine : process (k)
begin
--if (CLK_2X'EVENT and CLK_2X = '1') then
case k is
when 1 =>
--Initialization value at check nodes input coming from variable
node 1
v2c1_1 <= channelbit1;
v2c4_1 <= channelbit1;
v2c6_1 <= channelbit1;
received_1<= channelbit1;
--Initialization value at check nodes input coming from variable
node 2
v2c2_2 <= channelbit2;
v2c3_2 <= channelbit2;
v2c4_2 <= channelbit2;
received_2<= channelbit2;
--Initialization value at check nodes input coming from variable
node 3
v2c1_3 <= channelbit3;
v2c2_3 <= channelbit3;
v2c4_3 <= channelbit3;
received_3<= channelbit3;
--Initialization value at check nodes input coming from variable
node 4
v2c2_4 <= channelbit4;
v2c3_4 <= channelbit4;
v2c5_4 <= channelbit4;
received_4<= channelbit4;
--Initialization value at check nodes input coming from variable
node 5
v2c2_5 <= channelbit5;
v2c5_5 <= channelbit5;
v2c6_5 <= channelbit5;
received_5<= channelbit5;
--Initialization value at check nodes input coming from variable
node 6
v2c1_6 <= channelbit6;
v2c3_6 <= channelbit6;
v2c6_6 <= channelbit6;
received_6<= channelbit6;
--Initialization value at check nodes input coming from variable
node 7
v2c1_7 <= channelbit7;
v2c2_7 <= channelbit7;
v2c5_7 <= channelbit7;
received_7<= channelbit7;
--Initialization value at check nodes input coming from variable
node 8
v2c3_8 <= channelbit8;
v2c4_8 <= channelbit8;
v2c6_8 <= channelbit8;
received_8<= channelbit8;
--Initialization value at check nodes input coming from variable
node 9
v2c1_9 <= channelbit9;
v2c3_9 <= channelbit9;
v2c4_9 <= channelbit9;
received_9<= channelbit9;
--Initialization value at check nodes input coming from variable
node 10
v2c3_10 <= channelbit10;
v2c5_10 <= channelbit10;
v2c6_10 <= channelbit10;
received_10<=channelbit10;
--Initialization value at check nodes input coming from variable
node 11
v2c4_11 <= channelbit11;
v2c5_11 <= channelbit11;
v2c6_11 <= channelbit11;
received_11<= channelbit11;
--Initialization value at check nodes input coming from variable
node 12
v2c1_12 <= channelbit12;
v2c2_12 <= channelbit12;
v2c5_12 <= channelbit12;
received_12<= channelbit12;
when 7|13|19|25| =>
--Incoming messages to check node 1
-- Or outgoing messages from varaible nodes to check node 1
v2c1_1 <= v2c11;
v2c1_3 <= v2c31;
v2c1_6 <= v2c61;
v2c1_7 <= v2c71;
v2c1_9 <= v2c91;
v2c1_12 <= v2c121;
--Incoming messages to check node 2
-- Or outgoing messages from varaible nodes to check node 2
v2c2_2 <= v2c22;
v2c2_3 <= v2c32;
v2c2_4 <= v2c42;
v2c2_5 <= v2c52;
v2c2_7 <= v2c72;
v2c2_12 <= v2c122;
--Incoming messages to check node 3
-- Or outgoing messages from varaible nodes to check node 3
v2c3_2 <= v2c23;
v2c3_4 <= v2c43;
v2c3_6 <= v2c63;
v2c3_8 <= v2c83;
v2c3_9 <= v2c93;
v2c3_10 <= v2c103;
--Incoming messages to check node 4
-- Or outgoing messages from varaible nodes to check node 4
v2c4_1 <= v2c14;
v2c4_2 <= v2c24;
v2c4_3 <= v2c34;
v2c4_8 <= v2c84;
v2c4_9 <= v2c94;
v2c4_11 <= v2c114;
--Incoming messages check node 5
-- Or outgoing messages from varaible nodes to check node 5
v2c5_4 <= v2c45;
v2c5_5 <= v2c55;
v2c5_7 <= v2c75;
v2c5_10 <= v2c105;
v2c5_11 <= v2c115;
v2c5_12 <= v2c125;
--Incoming messages to check node 6
-- Or outgoing messages from varaible nodes to check node 6
v2c6_1 <= v2c16;
v2c6_5 <= v2c56;
v2c6_6 <= v2c66;
v2c6_8 <= v2c86;
v2c6_10 <= v2c106;
v2c6_11 <= v2c116;
start <= '0';
when 2|8|14|20|26=>
--Incoming messages to variable node 1
-- Or outgoing messages from check nodes to variable node 1
c2v11 <= c2v1_1;
c2v14 <= c2v4_1;
c2v16 <= c2v6_1;
--Incoming messages to variable node 2
-- Or outgoing messages from check nodes to variable node 2
c2v22 <= c2v2_2;
c2v23 <= c2v3_2;
c2v24 <= c2v4_2;
--Incoming messages to variable node 3
-- Or outgoing messages from check nodes to variable node 3
c2v31 <= c2v1_3;
c2v32 <= c2v2_3;
c2v34 <= c2v4_3;
--Incoming messages to variable node 4
-- Or outgoing messages from check nodes to variable node 4
c2v42 <= c2v2_4;
c2v43 <= c2v3_4;
c2v45 <= c2v5_4;
--Incoming messages to variable node 5
-- Or outgoing messages from check nodes to variable node 5
c2v52 <= c2v2_5;
c2v55 <= c2v5_5;
c2v56 <= c2v6_5;
--Incoming messages to variable node 6
-- Or outgoing messages from check nodes to variable node 6
c2v61 <= c2v1_6;
c2v63 <= c2v3_6;
c2v66 <= c2v6_6;
--Incoming messages to variable node 7
-- Or outgoing messages from check nodes to variable node 7
c2v71 <= c2v1_7;
c2v72 <= c2v2_7;
c2v75 <= c2v5_7;
--Incoming messages to variable node 8
-- Or outgoing messages from check nodes to variable node 8
c2v83 <= c2v3_8;
c2v84 <= c2v4_8;
c2v86 <= c2v6_8;
--Incoming messages to variable node 9
-- Or outgoing messages from check nodes to variable node 9
c2v91 <= c2v1_9;
c2v93 <= c2v3_9;
c2v94 <= c2v4_9;
--Incoming messages to variable node 10
-- Or outgoing messages from check nodes to variable node 10
c2v103 <= c2v3_10;
c2v105 <= c2v5_10;
c2v106 <= c2v6_10;
--Incoming messages to variable node 11
-- Or outgoing messages from check nodes to variable node 11
c2v114 <= c2v4_11;
c2v115 <= c2v5_11;
c2v116 <= c2v6_11;
--Incoming messages to variable node 12
-- Or outgoing messages from check nodes to variable node 12
c2v121 <= c2v1_12;
c2v122 <= c2v2_12;
c2v125 <= c2v5_12;
start <= '1';
when others =>
Null;
end case ;
-- end if ;
end process state_machine;
multiplication: Process (kk )
-- Multiplication Process Long enough not mentioned
Article: 63036"Martin Thompson" wrote: > Indeed it would, I think I must have dropped a factor of 10 somewhere, > sorry about that! 'been there, done that, paid for it dearly... :-( > How about we say that 1-2cm is close enough (for the HF decouplers?) That would seem to be the case. > > For my last design truly labored over this and took the approach of > > writing a custom power distribution system simulation tool in order to > > get a handle on what was going on. ... > Agreed - I did much the same thing here. What's scary is that no matter how much you research the subject it's hard to achieve convergence. It seems that everyone has a different --and perfectly valid-- reason why it should be done differently. As is the case with many things in engineering you have no choice but to abandon the search for the truth, pick an approach you're comfortable with, and move on. > capacitance? We put two 3.3V/GND 4thou separation pairs in the board, > which got us a few nF of very low inductance capacitance, which comes > in handy at the top end. Did that, exactly. > I came to the conclusion that above 100-150MHz you couldn't do a lot > with capacitors anyway. Probably true for discrete capacitors. I remember looking into these BGA packaged cap arrays that seemed to do quite well at high frequencies. > > ESR). If you run the curves, you want some ESR to mitigate peaky > > resonance effects. > > > > You could always fit some small resistors in series :-) Funny enough, I did think about this. The more I looked at the calculations and the curves the more I realized that you do want more series resistance with your decouplers. Sort of counter-intuitive in looking at the problem superficially, but makes perfect sense in the context of a power distribution system. Well, I didn't want to be the first fool to try to double-stack 0402 chip caps with 0402 chip resistors. I'll leave that excercise for those who might be substantially better funded than I am (enough to redo a board)! :-) > Apologies again for my arithmetic! See what happens when you don't use an RPN calculator! -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 63037
"Peter Alfke" wrote: > I like using BlockRAMs for unconventional applications ... Is there an app note or techxclusives article listing unconventional uses of BlockRAM's and multipliers? That could be useful to trigger some creative thinking. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 63038
"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:%gKsb.733$Nw.45922360@newssvr21.news.prodigy.com... > "Peter Alfke" wrote: > > I like using BlockRAMs for unconventional applications > > Is there an app note or techxclusives article listing > unconventional uses of BlockRAM's and multipliers? > That could be useful to trigger some creative thinking. Don't be silly; if it's in a Xilinx appnote, it's _ipso facto_ conventional :-) -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 63039
Hi, Does anybody know, whether Xilinx Virtex2 FPGA supports internal tristate? (the tristate that can't be pushed towards the interface or pins). Thanks in advance, VivekArticle: 63040
Vivek <viveklk@hotmail.com> wrote: : Hi, : Does anybody know, whether Xilinx Virtex2 FPGA supports internal tristate? : (the tristate that can't be pushed towards the interface or pins). Look for TBUFs -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 63041
"Isaac" <fpga_uk@yahoo.co.uk> wrote in message news:889eb3fb.0311130341.64adc04d@posting.google.com... > Can any body pin point the problem....In state s6 > I am reading out the > values from FPGA. State s2 and s3 are not defined. Oh, please..... * You have posted more than 400 lines of code. * The code contains no useful comments whatever. * Most of the signal names are incomprehensible. * All the state names are meaningless. * Many of the process sensitivity lists contain signals that they do not need. Kindly put in the effort to isolate the problem more carefully. As part of that process, you should document your code. This documentation will help you in understanding what's going on for yourself. If you still have a problem after you have done this, then at least you will be able to post something manageable and there is some chance that someone will try to help you. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 63044
Hi, I designed a FPGA prototyping board with a Spartan XC2S200E and a XC18V02 PROM. To configure these devices I put a JTAG header on the board and routed it as described in the following Xilinx datasheet: http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/designing7.html At the software-side I use impact and the PC3 from Xilinx. When I start impact in boundary-scan mode, the PC3 will be detected (as PC3@200kHz) and the boundary-scan chain will be identified. But there's the problem: impact always detects 11 devices in the chain, but there are only two. And: Even though the two devices are original Xilinx parts, no ID codes were returned (or better: the returned codes don't match with Xilinx parts). I checked the configuration connections and the power supply, but everything seems to be o.k. Has anybody of you an idea what the problem could be? thanks, KayArticle: 63045
In article <bopldr$1h0son$1@ID-212430.news.uni-berlin.de>, valentin@abelectron.com says... > It is not the same as Programmable GND Pins on Unused I/O. I can choose > between Keeper and Float. There is no information about this property. > > Look at the 'bus bold circuitry' in the XC9500XL date sheet and at answer #5175 in the Xilinx answer data base. Best regards -- Klaus Falser Durst Phototechnik AG kfalser@IHATESPAMdurst.itArticle: 63046
HI,
You didn't say anything about the frequency, so maybe for lower =
frequencies one way is to cascade 2 of these 2f circuits to get a 4f =
frequency and then using a simple flipflop to divide it by two, get a =
perfect 50% duty cycle 2f signal.
Best Regards
Arash
"Gazelle" <wmu@pandora.be> wrote in message =
news:S_vsb.20088$Q87.707719@phobos.telenet-ops.be...
Good day gents,
I am wondering if VHDL (or Verilog) code =
exists in order to make a frequency doubler in a normal
CPLD (without internal DDL/DPL/PLL infrastructure ) with a symmetric =
duty cycle.
Below some code can be found which generates a by-2 multiplied =
frequency - however the duty cycle
is very assymmetrical ...
Many thanks for your input !
Regards,
Michel
-- Frequency Doubler using DFF
-- code in VHDL
library ieee;
use ieee.std_logic_1164.all;
entity F2 is
port (fi : in std_logic; -- Input signal fi
fo : out std_logic); -- fo =3D 2*fi
end F2;
architecture behav of F2 is
signal clk : std_logic;
signal q : std_logic;
signal notq : std_logic;
begin
process (clk) begin
if (clk 'event and clk =3D '1') then
q <=3D notq;
end if;
end process;
notq <=3D not q ;
clk <=3D (notq xnor fi) ;
fo <=3D clk;
end behav;
Article: 63047"yes" I opened the Virtex-II datasheet (Functional Description) and the info was RIGHT THERE in the bookmarks, "3-State Buffers." "Vivek" <viveklk@hotmail.com> wrote in message news:a5bfe71f.0311130424.5dd09bfb@posting.google.com... > Hi, > > Does anybody know, whether Xilinx Virtex2 FPGA supports internal tristate? > (the tristate that can't be pushed towards the interface or pins). > > Thanks in advance, > > VivekArticle: 63048
Kay, I assume that you were using initialize chain to detect the devices. I also assume that you're using 6.1isp2 iMPACT to perform configuration. When iMPACT performs chain initialization, only TMS and TCK are toggled. Take a look at Xilinx soln 11857. So if the chain isn't detected correct, you'll want to probe the TMS, TCK, and TDO pins of each device. (ie. are the pins connected correctly, anything shorted, etc...) Other possible causes includes board SI, parallel port noise. You may want to contact the Xilinx hotline support for further help. Regards, Wei Kay Schubert wrote: > Hi, > > I designed a FPGA prototyping board with a Spartan XC2S200E and a XC18V02 > PROM. > To configure these devices I put a JTAG header on the board and routed it as > described in > the following Xilinx datasheet: > http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/designing7.html > > At the software-side I use impact and the PC3 from Xilinx. When I start > impact in boundary-scan mode, > the PC3 will be detected (as PC3@200kHz) and the boundary-scan chain will > be identified. But there's the problem: > impact always detects 11 devices in the chain, but there are only two. > And: Even though the two devices are original Xilinx parts, no ID codes were > returned (or better: the returned codes > don't match with Xilinx parts). > > I checked the configuration connections and the power supply, but > everything seems to be o.k. Has anybody of you an idea what the problem > could be? > > thanks, Kay > >Article: 63049
Jonathan Bromley wrote:
> "Isaac" <fpga_uk@yahoo.co.uk> wrote in message
> news:889eb3fb.0311130341.64adc04d@posting.google.com...
>>
>>Can any body pin point the problem....In state s6
>>I am reading out the
>>values from FPGA. State s2 and s3 are not defined.
>
> Oh, please.....
>
> * You have posted more than 400 lines of code.
> * The code contains no useful comments whatever.
> * Most of the signal names are incomprehensible.
> * All the state names are meaningless.
> * Many of the process sensitivity lists contain
> signals that they do not need.
>
> Kindly put in the effort to isolate the problem
> more carefully. As part of that process, you should
> document your code. This documentation will help
> you in understanding what's going on for yourself.
Jonathan, you left out a few:
* processes without names/labels
* long 'if/elsif' statements where 'case' is more appropriate
* 'Std_Logic_Arith' used instead of 'Numeric_Std'
* and finally <TABs> instead of <spaces> (#note 1)
This has to be the worst example of bad coding style that I've come across in a
long time - LOL
#note 1 people who use tabs in source code should be
hung drawn and quartered!.............. IMHO ;-)
--
Regards,
Brent Hayhoe.
Aftonroy Limited
Email: <A
HREF="mailto:Brent.Hayhoe@Aftonroy.com">
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