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
On 2007-03-09, Sylvain Munaut <tnt-at-246tNt-dot-com@youknowwhattodo.com> wrote: > Hi everyone, > > I just installed a new workstation, a Core2 duro running linux 64 bits. > But I can use data2bram on it, it crashes every time. I've tested with both 8.2 and 9.1 (both with latest service pack). For 8.2 I even tried the 32b and the 64 version. > > Using this utility is really important for me to update picoblaze and microblaze software without a need to recompile each time I want to test a new firmware. > > Has anyone encountered such an issue ? I once came upon a system where data2mem would crash completely under Windows. To make the matter worse this was during a visit to a company in Shanghai and I really needed to get the design working quickly on their machine. I don't remember what I did to solve this but I'm afraid that I gave up on data2mem and just recompiled the design every time. If I remember correctly I have also encountered some crashes if the input files to data2mem are not correct (such as errors in the .bmm file). You could also try to run data2mem on a different machine. data2mem does not depend on any other Xilinx library so you don't need a full install. Another way to solve your problem if you have no luck at all in getting data2mem to work could be to use the following flow: xdl -ncd2xdl yourdesign.ncd perl acustomperlscript.pl yourdesign.xdl yourbramcontents.txt xdl -xdl2ncd yourdesign.xdl Unfortunately this would not be very well integrated into the EDK flow (which I assume you are using for microblaze at least). Not to mention that you would have to write the perl script yourself. /AndreasArticle: 116451
Just to let you know, the problem is solved now. There were two issues with IMPACT: a) When IMPACT didn't prompt for the .NKY file during the program operation (for example because it was already set from a previous program), it also didn't include the the key load sequence - despite the checkbox marked. b) Once the load sequence makes it to the XSVF, it contains readback commands with TDO compare (fails). Replacing the compare mask with zeroes fixes this and the XSVF works. I hope this helps others with the same problem in the future. Regards, MarcArticle: 116452
On 8 Mrz., 23:04, n...@puntnl.niks (Nico Coesel) wrote: > Hello all, > Does anyone has some numbers on the frequency spectrum of the jitter > from a DCM? The datasheet says the DCM has a jitter of 100ps but I > would like to know a bit more about the spectrum to determine whether > or not the clock from a DCM is usefull for sampling. > > -- > Reply to nico@nctdevpuntnl (punt=.) > Bedrijven en winkels vindt U opwww.adresboekje.nl As i wanted to use a Spartan DCM i was also a bit sceptic how the Spectral Quality of it's generated clocks would be. First thing i did was Measure it with LeCroy Jitter Analysis. I did a JitterPeriod (which measures all the period's for one shot) followed by a FFT of these periods. I could not observe any significant spectral spikes this way other than what was caused by other things (power supply, crosstalk inside the logic, etc). The spectral quality was good. But the bad thing about the DCM is it's "digital" behaviour compared to a classic PLL. Everything is fine as long as you supply a near ideal Clock to it's input. If you don't, you are lost. You can't use it as a jitter filter or as a clock recovery as you could with a classic PLL. And you have to be very careful and do extra effort in you design when there is a possibility the clock to a DCM can be disturbed (ESD, EMC). I found out that there was noArticle: 116453
You could try explicitly instantiating a BUFG/BUFGCTRL between CLK0 and CLKFB instead of feeding dcm_0_FB back directly - the error message complains that only BUFG/BUFGCTRL/PLL_ADV can be the source for CLKFB. That is what I did to fix DCM synthesis warnings. Environment variables is a major annoyance if you work on stuff on more than one PC and either forget to set them or someone else changes them. Instantiating costs a few extra lines but after that, you'll never have to worry about them mysteriously disappearing again. Rebecca wrote: > Hello, Bill: > Thank you very much for your response. > Buf after I set up the enviroment variable and run the route again, I > got the same error several hours later. What can I do? > When I set the DCM as the top file and do the implementation, the .bit > file can be generated successfully. > But when I put my vhdl files (include dcm3.vhd) as a uer define core > in the EDK, I always got the above error. The system in the EDK also > incudes a DCM. Is there something wrong as shown: > BEGIN dcm_module > PARAMETER INSTANCE = dcm_0 > PARAMETER HW_VER = 1.00.a > PARAMETER C_CLK0_BUF = TRUE > PARAMETER C_CLKDV_BUF = TRUE > PARAMETER C_CLKDV_DIVIDE = 5.000000 > PARAMETER C_CLKIN_PERIOD = 10.000000 > PARAMETER C_CLK_FEEDBACK = 1X > PARAMETER C_DLL_FREQUENCY_MODE = LOW > PARAMETER C_EXT_RESET_HIGH = 1 > PORT CLKIN = dcm_clk_s > PORT CLKDV = sys_clk_s > PORT CLK0 = dcm_0_FB > PORT CLKFB = dcm_0_FB > PORT RST = net_gnd > PORT LOCKED = dcm_0_lock > END >Article: 116454
"nfirtaps" <lloyd.rochester@gmail.com> wrote in message news:1173403110.735187.326520@t69g2000cwt.googlegroups.com... > The problem I am having maybe due to jitter. I am not sure. I am > running under 35 MHz, althougth I am using LVDS. I am sampling on the > rising and falling edge of the clock, and the deserializer needs to > take every 7 clocks (respective 14 bits) since it is DDR. When I look > at the output clk/7 that I generate by a simple counter (when counter > = 1-4 clk is high, when counter = 4-7 clk is low), I see that the duty > cycle changes by about 1 clock. It seems as though the counter misses > a beat or something of that nature. If I understand what you're saying, it doesn't sound like it's anything to do with picking-up the falling-edges - surely your count-to-seven is only trigged off the positive edges anyway? Can you post some HDL for this? WillArticle: 116455
I just got an invitation to this years SIlica/Xilinx X-fest. I've been to these before and found them useful so I was registering to attend until I came to this bit: I grant Avnet, Inc. (avnet), its affiliates, subsidiaries, assigns, licensees, and design irrevocable right to use my name, picture, likeness and/or photograph, and biography information ( collectively the "materials") in all forms and media now known or hereby developed, and in all manners, including composite or distorted representations, for marketing, trade, editorial, and any other purposes whatsoever. I waive any right to approve any uses that may be created in connection therewith, or the use to which Materials may be applied. I agree that the Materials, the negatives, and other originals shall constitute Avnet's sole property, with full right of disposition in any manner whatsoever. I hereby release, discharge, and agree to hold harmless Avnet, its affiliates, subsidiaries, assigns, licensees, and designees, and all persons acting under its permission or anyone from any and all claims whatsoever in connection with the use of the materials. I have read the release and am fully familiar with its contents. I choked on that so I'll stick with Lattice for another design or two. Michael Kellett www.mkesc.co.ukArticle: 116456
"MK" <nospam@please.com> wrote in message news:rZGdnXTDH5Blx2zYRVnyjwA@bt.com... >I just got an invitation to this years SIlica/Xilinx X-fest. > > I've been to these before and found them useful so I was registering to > attend until I came to this bit: > > I grant Avnet, Inc. (avnet), its affiliates, subsidiaries, assigns, > licensees, and design irrevocable right to use my name, picture, likeness > and/or photograph, and biography information ( collectively the > "materials") in all forms and media now known or hereby developed, and in > all manners, including composite or distorted representations, for > marketing, trade, editorial, and any other purposes whatsoever. I waive > any right to approve any uses that may be created in connection therewith, > or the use to which Materials may be applied. I agree that the Materials, > the negatives, and other originals shall constitute Avnet's sole property, > with full right of disposition in any manner whatsoever. I hereby release, > discharge, and agree to hold harmless Avnet, its affiliates, subsidiaries, > assigns, licensees, and designees, and all persons acting under its > permission or anyone from any and all claims whatsoever in connection with > the use of the materials. I have read the release and am fully familiar > with its contents. > > > I choked on that so I'll stick with Lattice for another design or two. > > Michael Kellett > > www.mkesc.co.uk > Sorry about typo in subject - rage must have got the better of me ! MKArticle: 116457
Your main problem is that the temperature and voltage variations that you're going to get in the FPGA will by FAR outweight the 10ps you're looking for. To prove this to yourself, take a simple design and run it through your place and route tools. Then open up timing analyzer and look at a path, any path at all. But make sure to select the option to give you both setup & hold paths. This is best case and worst cast. Lowest voltage & highest temperature is your setup path or worst case delay.... highest voltage and lowest temperature is your best case delay or hold path. I promise you those two numbers will vary by more than 10ps for almost any route in your part. Even the virtex 5, which can give you a temp/voltage compensated output delay (the virex 4 would give you an input dealy, but no output) only has a delay resolution in the order of 75ps. Anywho... if ya think about it - 10ps is a 100GHz signal.... there's a reason FPGAs currently max out in the 500MHz range.... the variations are just too big over temp and voltage. That's also why FPGA designs are usually synchronous designs and the level sensitive world is generally left to ASICs. That being said... you're going to have a hard time getting a reliable 10ps delay in any manner - even analog sorts of manners - unless you're in a strictly controlled environment.... but good luck :) -Paul On Mar 7, 4:59 pm, "axr0284" <axr0...@yahoo.com> wrote: > Hi, > I would like to know what are the common methods of introducing > delays as low as 10ps between two outputs in an FPGA. I do not > currently have a specific FPGA in mind. I am just looking for a > general answer. > > I know there are DCMs but this usually adds jitter and one needs to > wait for the DCM output to phase lock before the signal is stable and > it might take too long in our case. Basically I would want to power up > a board and have the delay be set in as short a time as possible. I > also need to minimise jitter to a minimum so that the two signals are > NEVER high at the same time. Thanks for any answer. > AmishArticle: 116458
"I personally see the FPGAs following a road that leads them to looking a lot like microcontrollers but with FPGA fabric where the processor is." .... Wrong way around... FPGA fabric where the controllers are, hard silicon where the processor is... and they've already done this... virtex FX series parts - powerPC in hard silicon, runs the speed of a power pc in hard silicon (fast) surrounded by FPGA fabric that you can do whatever you need to with.... On Mar 7, 2:01 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote: > I personally see the FPGAs following a road that leads them to looking a > lot like microcontrollers but with FPGA fabric where the processor is. > > ---Matthew Hicks > > > > > Hi, > > I just got a newsletter stating the Spartan3AN being available now. > > While > > these Spartan3AN are market as "new non-volatile" FPGAs, this might > > (IMHO) > > be misleading. For my understanding "non-volatile" would mean no > > configuration on power-ON (as e.g. ACTEL AntiFuse) rather than > > Config-Eprom > > being integrated in FPGA chip's housing (being a separate die as > > well). > > Nevertheless this definitely is a nice appraoch, saving space and > > copper > > traces on PCB. > > As always, as soon as the new chip is on market the question on next > > enhancements arises. Any truth in rumors stating next generation > > Spartan (or > > what it will be called) has integrated Analog-Digital Converters? > > CU, Carlhermann Schlehaus- Hide quoted text - > > - Show quoted text -Article: 116459
Thomas Stanka wrote: > Hi, > > I feel you are talking about fullcustom ICs when talking about ASICs. > There exist fix predesigned technology libs when doing cell based > design, and Sea-of-Gate ASIC didn't allow to include anything not > available in the technology. Mask-programmable cell/gate arrays are one step closer to being ASICs than partially mask-programmable FPGAs like Xilinx's EasyPath... but they are only mask-programmable devices and therefore not quite application-specific since, as you said, you cannot specify anything that does not happen to be part of the mass-prefabricated blanks. To me, an ASIC is only limited by budget, power, surface area, the laws of physics, current process technology, IP licensing agreements and patents. A mask-programmable device is very ASIC-like for routing but is still limited by the blank provider's choice and placement of individual blocks. >> So, for me, the most significant difference between ASIC and FPGA after the development >> cost and production timetable is having to license all the low-level nuts and bolts if I >> want to be able to concentrate on the higher-level functions I wish to implement without >> having to worry about going through a dozen re-spins just to get the low-level stuff like >> FFs and IOBs to work properly. > > This is not true for the cell based design I worked on. If you work with mask-programmable devices, all the transistor-level and delicate timing details are hidden in the blank's cells and have been taken care of long before you instantiated or inferred that first NAND gate in the middle of your design. But before Fujitsu could start marketing those mask-programmable devices, Fujitsu engineers have certainly gone through many respins of these to fine-tune all available functions so their customers would not have to worry about them, just like foundries keep refining their process technology and primitives libraries so ASIC engineers can license them and not have to worry about wasting respins only to make them work since they have been extensively tested in the foundry's own fabs and silicon-proven in multiple other clients' designs. For specialized functions, sometimes there are unforeseen complications such as Rambus refusing to work with a specific foundry to qualify their XDR and PCIe macros on your preferred foundry's 90nm process, in which case you end up having to can XDR, rework your design to use DDR2/3 instead and hunt down some other PCIe provider who will work with your foundry or already has a qualified macro... I wasted over a month updating test sequences affected by such changes and it took many months to iron out all the glitches caused by the memory controller swap. Designing around a piece of IP for months only to see the contract negotiations stall then fall through for arbitrary reasons makes working with hard-macro IP cores rather 'interesting'.Article: 116460
Hi group In order to keep traces as short as possible I would like to route the PHY's MII interface to the built in EMAC0 with as short traces as possible. Xilinx consequently recommends to use IOs which are close to the EMAC. However, I could not find documentation (I'm aparently overlooking it) close to which bank the EMAC is located..... So does anyone know and tell me? While we are at it, where's the PPC core? This is for a Virtex 4 FX 12 btw. TIA MarkusArticle: 116461
On Mar 9, 9:19 am, Markus Zingg <m.zi...@nct.ch> wrote: > Hi group > > In order to keep traces as short as possible I would like to route the > PHY's MII interface to the built in EMAC0 with as short traces as > possible. Xilinx consequently recommends to use IOs which are close to > the EMAC. However, I could not find documentation (I'm aparently > overlooking it) close to which bank the EMAC is located..... So does > anyone know and tell me? While we are at it, where's the PPC core? > > This is for a Virtex 4 FX 12 btw. > > TIA > > Markus You can use the FPGA editor that is part of ISE to look at where the EMAC and PPC are located with respect to the pins/pads for the package that you are using. Regards, John McCaskill www.fastertechnology.comArticle: 116462
Will here I have the entire serializer, it looks like a lot of code
but most all the lines are repeated. Just to clarify it desrialized 14
bits of a ddr signal. So every 7 clock cycles the 14-bit word is
latched. Clk is the signal that is the clock that has a problem with
duty cycle, it is driven by toggler and toggler is driven by the
counter. Thanks so much for you help. Having a group like this is
extremely valuable.
ENTITY ad9259deser IS
-- {{ALTERA_IO_BEGIN}} DO NOT REMOVE THIS LINE!
PORT
(
dco : IN STD_LOGIC;
fco : IN STD_LOGIC;
sera : IN STD_LOGIC;
serb : IN STD_LOGIC;
serc : IN STD_LOGIC;
serd : IN STD_LOGIC;
cha : out STD_LOGIC_VECTOR(13 downto 0);
chb : out STD_LOGIC_VECTOR(13 downto 0);
chc : out STD_LOGIC_VECTOR(13 downto 0);
chd : out STD_LOGIC_VECTOR(13 downto 0);
clk : out STD_LOGIC
);
-- {{ALTERA_IO_END}} DO NOT REMOVE THIS LINE!
END ad9259deser;
-- Architecture Body
ARCHITECTURE ad9259deser_architecture OF ad9259deser IS
signal ba0,ba1,ba2,ba3,ba4,ba5,ba6,ba7,ba8,ba9,ba10,ba11,ba12,ba13 :
std_logic := '0';
signal
ba14,ba15,ba16,ba17,ba18,ba19,ba20,ba21,ba22,ba23,ba24,ba25,ba26,ba27 :
std_logic := '0';
signal bb0,bb1,bb2,bb3,bb4,bb5,bb6,bb7,bb8,bb9,bb10,bb11,bb12,bb13 :
std_logic := '0';
signal
bb14,bb15,bb16,bb17,bb18,bb19,bb20,bb21,bb22,bb23,bb24,bb25,bb26,bb27 :
std_logic := '0';
signal chat,chbt : std_logic_vector(13 downto 0);
signal count_dco : unsigned(4 downto 0) := (others=>'0');
signal count_fco : unsigned(4 downto 0) := (others=>'0');
signal toggler : std_logic := '0';
signal go : std_logic := '0';
signal test : std_logic;
BEGIN
process(fco)
begin
if(fco'event and fco='1') then
go <= '1';
end if;
end process;
process(dco)
begin
if (dco'event and dco = '1' and go = '1') then
count_dco <= count_dco+1;
chd <= "000000000" & std_logic_vector(count_dco);
chc <= "000000000" & std_logic_vector(count_fco);
clk <= toggler;
if (count_dco = 13) then -- every 14 cycles a new word is latched
chat(13) <= ba27;
chat(12) <= ba26;
chat(11) <= ba25;
chat(10) <= ba24;
chat( 9) <= ba23;
chat( 8) <= ba22;
chat( 7) <= ba21;
chat( 6) <= ba20;
chat( 5) <= ba19;
chat( 4) <= ba18;
chat( 3) <= ba17;
chat( 2) <= ba16;
chat( 1) <= ba15;
chat( 0) <= ba14;
chbt(13) <= bb27;
chbt(12) <= bb26;
chbt(11) <= bb25;
chbt(10) <= bb24;
chbt( 9) <= bb23;
chbt( 8) <= bb22;
chbt( 7) <= bb21;
chbt( 6) <= bb20;
chbt( 5) <= bb19;
chbt( 4) <= bb18;
chbt( 3) <= bb17;
chbt( 2) <= bb16;
chbt( 1) <= bb15;
chbt( 0) <= bb14;
cha <= not chat(13) & chat(12 downto 0);
chb <= not chbt(13) & chbt(12 downto 0);
toggler <= '1';
count_dco <= "00000";
elsif (count_dco = 4) then
toggler <= '0';
end if;
end if;
end process;
process(dco)
begin
if(dco'event and dco = '1') then
ba1 <= sera;
ba3 <= ba1;
ba5 <= ba3;
ba7 <= ba5;
ba9 <= ba7;
ba11 <= ba9;
ba13 <= ba11;
ba15 <= ba13;
ba17 <= ba15;
ba19 <= ba17;
ba21 <= ba19;
ba23 <= ba21;
ba25 <= ba23;
ba27 <= ba25;
bb1 <= serb;
bb3 <= bb1;
bb5 <= bb3;
bb7 <= bb5;
bb9 <= bb7;
bb11 <= bb9;
bb13 <= bb11;
bb15 <= bb13;
bb17 <= bb15;
bb19 <= bb17;
bb21 <= bb19;
bb23 <= bb21;
bb25 <= bb23;
bb27 <= bb25;
elsif(dco'event and dco = '0') then
ba0 <= sera;
ba2 <= ba0;
ba4 <= ba2;
ba6 <= ba4;
ba8 <= ba6;
ba10 <= ba8;
ba12 <= ba10;
ba14 <= ba12;
ba16 <= ba14;
ba18 <= ba16;
ba20 <= ba18;
ba22 <= ba20;
ba24 <= ba22;
ba26 <= ba24;
bb0 <= serb;
bb2 <= bb0;
bb4 <= bb2;
bb6 <= bb4;
bb8 <= bb6;
bb10 <= bb8;
bb12 <= bb10;
bb14 <= bb12;
bb16 <= bb14;
bb18 <= bb16;
bb20 <= bb18;
bb22 <= bb20;
bb24 <= bb22;
bb26 <= bb24;
end if;
end process;
END ad9259deser_architecture;
On Mar 9, 5:55 am, "Will Dean" <w...@nospam.demon.co.uk> wrote:
> "nfirtaps" <lloyd.roches...@gmail.com> wrote in message
>
> news:1173403110.735187.326520@t69g2000cwt.googlegroups.com...
>
> > The problem I am having maybe due to jitter. I am not sure. I am
> > running under 35 MHz, althougth I am using LVDS. I am sampling on the
> > rising and falling edge of the clock, and the deserializer needs to
> > take every 7 clocks (respective 14 bits) since it is DDR. When I look
> > at the output clk/7 that I generate by a simple counter (when counter
> > = 1-4 clk is high, when counter = 4-7 clk is low), I see that the duty
> > cycle changes by about 1 clock. It seems as though the counter misses
> > a beat or something of that nature.
>
> If I understand what you're saying, it doesn't sound like it's anything to
> do with picking-up the falling-edges - surely your count-to-seven is only
> trigged off the positive edges anyway?
>
> Can you post some HDL for this?
>
> Will
Article: 116463"Utku Özcan" <utku.ozcan@gmail.com> wrote in message news:1173384869.194349.20140@q40g2000cwq.googlegroups.com... > > Hi "news reader", my humble perls in between.. > > news reader schrieb: > >> In the design I have 256 3-bit registers, every time I need to read or >> write 16 of them (data_o0, 1, ...15). >> The read/write address is not totally random. > > It seems that you have an algorithm that handles a deterministic > distribution of the values to be accessed. Therefore you think you can > implement it with logic only. > > I assume you are modeling an algorithm for a special matrix operation. > It's not matrix, but the memory access is intensive, must accomplish r/w in single clock cycle, so register is used instead of memory. >> For example, assuming that I arrange the register into a 16X16 matrix, >> data_o0 accesses among the zeros row or column. data_o1 may access from >> 20 of the >> registers, but not 256, data_o2 may access from 30 of the variables, >> etc. > > The values do not give us much info. data_ox (x = 1, 2, ...) is > accessing which elements and in which distribution? > In each clock cycle, 16 addresses are generated, and 16 data are read/written. However, each of the 16 data is read/written only to n/256 addresses (0<n<255). >> If I code such that every output reads from the 256 registers, the final >> logic will be overkill and highly redundant. > > You think that the distribution of elements can be accessed with pure > logic. > Therefore you tried to model your logic to cover every case, or you > want to do it so. > >> If I use case statements to list each of the senarios, the RTL code may >> end >> up 500 kilobyte. > > This is reasonable then. > By means of case statement, I use 32 case statements, in each case statement there are less than 256 choices. Some have only 20, 30 choices, etc. >> Will design compiler synthesize a 500KB design efficiently? > > What means "efficience" for you? Speed or minimum logic? > If minimum logic, then please share with us the algorithm you are > trying to implement. > >> Will NCVerilog compile and simulate it efficiently? > > NCVerilog does not care about logic implementation. It defines the > behaviour of the system, no matter how the objects are linked. > For example in read operation, --------------------- implementation A------------------ input [7:0] addr_i0, addr_r1, ...addr_r15; output [2:0] dat_o0, dat_o1, ...dat_o15; reg [2:0] mymemory[0:255]; // Main memory dat_o0 <= mymemory[addr_i0]; dat_o1 <= mymemory[addr_i1]; .... dat_o15 <= mymemory[addr_i15]; --------------------- End A------------------ --------------------- implementation B------------------ case (addr_i0) // I can calculate these options through simulations. 8'd0 : dat_o0 <= mymemory[0 ]; 8'd5 : dat_o0 <= mymemory[5 ]; 8'd54 : dat_o0 <= mymemory[54 ]; 8'd122: dat_o0 <= mymemory[122]; 8'd125: dat_o0 <= mymemory[125]; ... 8'd166: dat_o0 <= mymemory[166]; 8'd233: dat_o0 <= mymemory[233]; default: dat_o0 <= mymemory[0 ]; endcase case (addr_i1) 8'd0 : dat_o1 <= mymemory[0 ]; 8'd7 : dat_o1 <= mymemory[7 ]; 8'd9 : dat_o1 <= mymemory[9 ]; 8'd13 : dat_o1 <= mymemory[13 ]; 8'd25 : dat_o1 <= mymemory[25 ]; 8'd57 : dat_o1 <= mymemory[57 ]; 8'd124: dat_o1 <= mymemory[124]; ... 8'd133: dat_o1 <= mymemory[133]; 8'd155: dat_o1 <= mymemory[155]; 8'd277: dat_o1 <= mymemory[277]; default: dat_o1 <= mymemory[0 ]; endcase ... case (addr_i15) ... --------------------- End B------------------ In terms of hardware implementation, is it certain that implementation B saves hardware compared to A? Will the large chunks of RTL codes causes a DC or NCVerilog to choke up? >> Are there any neater techniques to attack this problem? > > Since you have not given much data, I think you can implement this > stuff with a RAM. > Why don't you use a RAM? Then you can define the RAM addresses to > model your matrix. You will generate addresses to define the positions > for your matrix which mimics your algorithm. > I used registers instead of RAM due to the memory throughput. > Utku. >Article: 116464
On Mar 8, 9:27 pm, "Rob" <robns...@frontiernet.net> wrote: > If your input clock is not on the global clock network you will be fighting > with clock skew to the flops. When your clock edges are happening with > respect to the data at the flops becomes an utmost concern for you. > > "nfirtaps" <lloyd.roches...@gmail.com> wrote in message > > news:1173383894.763347.110110@64g2000cwx.googlegroups.com... > > >I am trying to deserialize a DDR signal in my Cyclone. For reasons I > > won't go into the DDR clock comes in off a general purpose I/O pin. I > > need a way of deserializing this signal, and want to increase the > > frequency of the DDR clock by 2 so I can use rising edge flip-flops. > > > 1.) Can I somehow drive a PLL with a general purpose I/O > > 2.) Is there another way of deserializing the DDR signal. > > > Currently I have a the DDR clock coming in my fpga and I not the clock > > so I can sample the DDR signal on the rising egde. > > > Thanks As for the clock not being part of the global clock network, Quartus gives me the following message "Info: Automatically promoted signal "dco" to use Global clock in PIN 29" so I guess my clock is put into the global network.Article: 116465
"nfirtaps" <lloyd.rochester@gmail.com> wrote in message news:1173456025.129640.67790@h3g2000cwc.googlegroups.com... > Will here I have the entire serializer, it looks like a lot of code > but most all the lines are repeated. Just to clarify it desrialized 14 > bits of a ddr signal. So every 7 clock cycles the 14-bit word is > latched. Clk is the signal that is the clock that has a problem with > duty cycle, it is driven by toggler and toggler is driven by the > counter. Thanks so much for you help. Having a group like this is > extremely valuable. It would be even more valuable if I was a VHDL person rather than a Verilog one, but it does appear that you're trying to count to 14, when I think I would be trying to count to 7, and dealing with two bits on every count. So you'd have one bit of code which just samples the data on the negative edge of the clock and stores it, and another bit which works on the positive edge of the block, samples one bit and stores BOTH bits into your shift register on each positive edge. Like I say, I'm not a VHDL person, but I suspect there is a rather neater way to write that code - hopefully someone else might offer some advice. You're also assigning to count_dco in two places when it's equal to 13 - I don't know how that gets synthesised in VHDL, but it's the kind of thing I avoid. Is this your original code or did you lift it from somewhere else? Have you tried a functional simulation of this? (In Modelsim or ActiveHDL, for example?) I don't really think you're doing anything terribly ambitious, and it's perhaps a bit early to be worrying about jitter and PLLs at this stage. (Don't be distracted by the efforts people make to get DDR266 interfaces working - that's a completely different type of problem.) WillArticle: 116466
On Mar 9, 9:25 am, "Will Dean" <w...@nospam.demon.co.uk> wrote:
> "nfirtaps" <lloyd.roches...@gmail.com> wrote in message
>
> news:1173456025.129640.67790@h3g2000cwc.googlegroups.com...
>
> > Will here I have the entire serializer, it looks like a lot of code
> > but most all the lines are repeated. Just to clarify it desrialized 14
> > bits of a ddr signal. So every 7 clock cycles the 14-bit word is
> > latched. Clk is the signal that is the clock that has a problem with
> > duty cycle, it is driven by toggler and toggler is driven by the
> > counter. Thanks so much for you help. Having a group like this is
> > extremely valuable.
>
> It would be even more valuable if I was a VHDL person rather than a Verilog
> one, but it does appear that you're trying
> to count to 14, when I think I would be trying to count to 7, and dealing
> with two bits on every count.
>
> So you'd have one bit of code which just samples the data on the negative
> edge of the clock and stores it, and another bit which works on the positive
> edge of the block, samples one bit and stores BOTH bits into your shift
> register on each positive edge.
>
> Like I say, I'm not a VHDL person, but I suspect there is a rather neater
> way to write that code - hopefully someone else might offer some advice.
>
> You're also assigning to count_dco in two places when it's equal to 13 - I
> don't know how that gets synthesised in VHDL, but it's the kind of thing I
> avoid.
>
> Is this your original code or did you lift it from somewhere else?
>
> Have you tried a functional simulation of this? (In Modelsim or ActiveHDL,
> for example?)
>
> I don't really think you're doing anything terribly ambitious, and it's
> perhaps a bit early to be worrying about jitter and PLLs at this stage.
> (Don't be distracted by the efforts people make to get DDR266 interfaces
> working - that's a completely different type of problem.)
>
> Will
Will I did make a cleaner version with no counters: here it is.
ENTITY ad9259deser IS
-- {{ALTERA_IO_BEGIN}} DO NOT REMOVE THIS LINE!
PORT
(
dco : IN STD_LOGIC;
fco : IN STD_LOGIC;
sera : IN STD_LOGIC;
serb : IN STD_LOGIC;
serc : IN STD_LOGIC;
serd : IN STD_LOGIC;
cha : out STD_LOGIC_VECTOR(13 downto 0);
chb : out STD_LOGIC_VECTOR(13 downto 0);
chc : out STD_LOGIC_VECTOR(13 downto 0);
chd : out STD_LOGIC_VECTOR(13 downto 0);
clk : out STD_LOGIC
);
-- {{ALTERA_IO_END}} DO NOT REMOVE THIS LINE!
END ad9259deser;
-- Architecture Body
ARCHITECTURE ad9259deser_architecture OF ad9259deser IS
signal dco_plus, dco_minus : std_logic;
signal ba0,ba1,ba2,ba3,ba4,ba5,ba6,ba7,ba8,ba9,ba10,ba11,ba12,ba13 :
std_logic := '0';
signal
ba14,ba15,ba16,ba17,ba18,ba19,ba20,ba21,ba22,ba23,ba24,ba25,ba26,ba27 :
std_logic := '0';
signal bb0,bb1,bb2,bb3,bb4,bb5,bb6,bb7,bb8,bb9,bb10,bb11,bb12,bb13 :
std_logic := '0';
signal
bb14,bb15,bb16,bb17,bb18,bb19,bb20,bb21,bb22,bb23,bb24,bb25,bb26,bb27 :
std_logic := '0';
signal chat,chbt : std_logic_vector(13 downto 0);
signal count_dco : unsigned(4 downto 0) := (others=>'0');
signal count_fco : unsigned(4 downto 0) := (others=>'0');
signal toggler : std_logic := '0';
signal go : std_logic := '0';
signal test : std_logic;
BEGIN
clk <= fco;
process(fco)
begin
if (fco'event and fco = '1') then
go <= '1';
chd <= "00000000000000";
chc <= "00000000000000";
chat(13) <= ba27;
chat(12) <= ba26;
chat(11) <= ba25;
chat(10) <= ba24;
chat( 9) <= ba23;
chat( 8) <= ba22;
chat( 7) <= ba21;
chat( 6) <= ba20;
chat( 5) <= ba19;
chat( 4) <= ba18;
chat( 3) <= ba17;
chat( 2) <= ba16;
chat( 1) <= ba15;
chat( 0) <= ba14;
chbt(13) <= bb27;
chbt(12) <= bb26;
chbt(11) <= bb25;
chbt(10) <= bb24;
chbt( 9) <= bb23;
chbt( 8) <= bb22;
chbt( 7) <= bb21;
chbt( 6) <= bb20;
chbt( 5) <= bb19;
chbt( 4) <= bb18;
chbt( 3) <= bb17;
chbt( 2) <= bb16;
chbt( 1) <= bb15;
chbt( 0) <= bb14;
cha <= not chat(13) & chat(12 downto 0);
chb <= not chbt(13) & chbt(12 downto 0);
end if;
end process;
process(dco)
begin
if(dco'event and dco = '1' and go = '1') then
count_dco <= count_dco + 1;
ba1 <= count_dco(3);
ba3 <= ba1;
ba5 <= ba3;
ba7 <= ba5;
ba9 <= ba7;
ba11 <= ba9;
ba13 <= ba11;
ba15 <= ba13;
ba17 <= ba15;
ba19 <= ba17;
ba21 <= ba19;
ba23 <= ba21;
ba25 <= ba23;
ba27 <= ba25;
bb1 <= serb;
bb3 <= bb1;
bb5 <= bb3;
bb7 <= bb5;
bb9 <= bb7;
bb11 <= bb9;
bb13 <= bb11;
bb15 <= bb13;
bb17 <= bb15;
bb19 <= bb17;
bb21 <= bb19;
bb23 <= bb21;
bb25 <= bb23;
bb27 <= bb25;
elsif(dco'event and dco = '0' and go = '1') then
ba0 <= sera;
ba2 <= ba0;
ba4 <= ba2;
ba6 <= ba4;
ba8 <= ba6;
ba10 <= ba8;
ba12 <= ba10;
ba14 <= ba12;
ba16 <= ba14;
ba18 <= ba16;
ba20 <= ba18;
ba22 <= ba20;
ba24 <= ba22;
ba26 <= ba24;
bb0 <= serb;
bb2 <= bb0;
bb4 <= bb2;
bb6 <= bb4;
bb8 <= bb6;
bb10 <= bb8;
bb12 <= bb10;
bb14 <= bb12;
bb16 <= bb14;
bb18 <= bb16;
bb20 <= bb18;
bb22 <= bb20;
bb24 <= bb22;
bb26 <= bb24;
end if;
end process;
END ad9259deser_architecture;
Article: 116467Michael, please let me know where you read this piece of nonsense. It seems that Avnet has a lawyer with too much time on his hands. I will try to twist their arm to eradicate this. I have a special interest in this, for I will give the Keynote Address in a few locations in Europe, and I don't want to face a hostile audience... Peter Alfke peter@xilinx.com On Mar 9, 5:04 am, "MK" <nos...@please.com> wrote: > I just got an invitation to this years SIlica/Xilinx X-fest. > > I've been to these before and found them useful so I was registering to > attend until I came to this bit: > > I grant Avnet, Inc. (avnet), its affiliates, subsidiaries, assigns, > licensees, and design irrevocable right to use my name, picture, likeness > and/or photograph, and biography information ( collectively the "materials") > in all forms and media now known or hereby developed, and in all manners, > including composite or distorted representations, for marketing, trade, > editorial, and any other purposes whatsoever. I waive any right to approve > any uses that may be created in connection therewith, or the use to which > Materials may be applied. I agree that the Materials, the negatives, and > other originals shall constitute Avnet's sole property, with full right of > disposition in any manner whatsoever. I hereby release, discharge, and agree > to hold harmless Avnet, its affiliates, subsidiaries, assigns, licensees, > and designees, and all persons acting under its permission or anyone from > any and all claims whatsoever in connection with the use of the materials. I > have read the release and am fully familiar with its contents. > > I choked on that so I'll stick with Lattice for another design or two. > > Michael Kellett > > www.mkesc.co.ukArticle: 116468
On Mar 8, 4:30 pm, Jim Lewis <j...@synthworks.com> wrote: > Weng, > > 2. Is there any general algorithm to change such an > > equation to a latch equation? > I have not seen any evidence of one you can expect different > tool vendors to support. > > For RTL code, if you want a synthesis tool to reliably > create a latch library part, only use #1 or #2 (below from > KJs post). Going further, if you want to avoid portability > issues with some of the ASIC synthesis tools, then use > only #1. > > >> #1 -- Traditional form of writing a latch > >> process(C, D) > >> begin > >> if (C='1') then > >> Q <= D; > >> end if; > >> end process; > > >> #2 -- Another traditional form of writing a latch. > >> Q <= D when (C = '1'); > > If you use other forms, a synthesis tool may generate > logic that implements latching behavior without using > a latch part. If you use these to deliberately create > a latch, good luck. > > Generally people accidentally create the other forms > when two separate pieces of logic communicate. > > Cheers, > Jim Hi Jim, I am not going to write an odd equation to confuse VHDL compilers that would be stupid, but just wondering about how can a VHDL compiler figure out its inherent complex structures. The best way to do FPGA design is to follow rules. No exceptions. >From this posing, I have learned how to write a latch correctly in standard VHDL form, how to use a new possible attribute to let VHDL compiler to generate an error information, instead of a warning information, and the last and not the least, how to avoid confusing VHDL compiler by using a signal name in both side of "<=" in concurrent area. Thank you. WengArticle: 116469
I wasn't clear in what I wrote, sorry. I ment, I wasn't talking about parts with processor cores in them. I basically ment that a future FPGA will be fabric surrounded by ADCs, DACs, Ethernet, SPI, I2C, VGA/DVI, USB, 1394 ... cores either hard for the more complicated stuff and soft for the simple things. Basically, I see a higher level of integration with the most commonly used items. ---Matthew Hicks > "I personally see the FPGAs following a road that leads them to > looking a > lot like microcontrollers but with FPGA fabric where the processor > is." > .... Wrong way around... FPGA fabric where the controllers are, hard > silicon where the processor is... and they've already done this... > virtex FX series parts - powerPC in hard silicon, runs the speed of a > power pc in hard silicon (fast) surrounded by FPGA fabric that you can > do whatever you need to with.... > > On Mar 7, 2:01 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote: > >> I personally see the FPGAs following a road that leads them to >> looking a lot like microcontrollers but with FPGA fabric where the >> processor is. >> >> ---Matthew Hicks >> >>> Hi, >>> I just got a newsletter stating the Spartan3AN being available now. >>> While >>> these Spartan3AN are market as "new non-volatile" FPGAs, this might >>> (IMHO) >>> be misleading. For my understanding "non-volatile" would mean no >>> configuration on power-ON (as e.g. ACTEL AntiFuse) rather than >>> Config-Eprom >>> being integrated in FPGA chip's housing (being a separate die as >>> well). >>> Nevertheless this definitely is a nice appraoch, saving space and >>> copper >>> traces on PCB. >>> As always, as soon as the new chip is on market the question on next >>> enhancements arises. Any truth in rumors stating next generation >>> Spartan (or >>> what it will be called) has integrated Analog-Digital Converters? >>> CU, Carlhermann Schlehaus- Hide quoted text - >> - Show quoted text - >>Article: 116470
Peter Alfke wrote: > Michael, please let me know where you read this piece of nonsense. > It seems that Avnet has a lawyer with too much time on his hands. > I will try to twist their arm to eradicate this. > I have a special interest in this, for I will give the Keynote Address > in a few locations in Europe, and I don't want to face a hostile > audience... Or no Audience at all :) Sounds to me like the 'Borat Effect', or maybe it's even the same Clause Borat used ? ;) Iike this bit especially "and in all manners, including composite or distorted representations, " Well, at least they are honest about marketing works.... -jgArticle: 116471
Jim Granville wrote: > Peter Alfke wrote: >> Michael, please let me know where you read this piece of nonsense. >> It seems that Avnet has a lawyer with too much time on his hands. >> I will try to twist their arm to eradicate this. >> I have a special interest in this, for I will give the Keynote Address >> in a few locations in Europe, and I don't want to face a hostile >> audience... > > Or no Audience at all :) From the email they sent me, follow this link: http://s107.inxserver.de/inxmail1/url?vpmeq00gshq00bzxu3a6 The junk at the end may be customer-specific, but it seems to be a generic link.Article: 116472
Matthew Hicks wrote: > I wasn't clear in what I wrote, sorry. I ment, I wasn't talking about > parts with processor cores in them. I basically ment that a future FPGA > will be fabric surrounded by ADCs, DACs, Ethernet, SPI, I2C, VGA/DVI, > USB, 1394 ... cores either hard for the more complicated stuff and soft > for the simple things. Basically, I see a higher level of integration > with the most commonly used items. ..and the processor guys are also comming from the other direction. http://www.st.com/stonline/stappl/press/news/year2007/p2142.htm ST have a couple more of their volume NRE (mask) Devices Design flow is like this : "Both the SPEAr Plus600 and the SpearHead600 come complete with a dedicated development board that allows developing and testing of the customer system with minimum time and resource requirements. By using an external FPGA that mirrors the SoCs internal configurable logic block, designers can proceed with the software and hardware development without waiting for the final validation. Once the customer SoC passes the functional qualification, full production can ramp up in eight weeks time from the final RTL availability." Looking at your list: Y ADCs, ~ DACs, Y Ethernet, ? SPI, (probably there somewhere..) Y I2C, ~ VGA/DVI, LCD support anyway ~ USB, Yes, with the PHY N 1394 ( market too small ) you missed RTC, DualARM926 cores, and the biggest challenge of all (for the FPGA vendors) :- achieving a sensible Icc level "The price is $12 for the SPEAr Plus600 and $10 for the SPEAr Head 600, in quantities of 20,000 pieces." for what they offer, those prices are not bad, and it will be interesting to see where these devices end up. -jgArticle: 116473
As the Bard of Avon wrote in Henry VI: "JACK CADE. I thank you, good people:- there shall be no money; all shall eat and drink on my score; and I will apparel them all in one livery, that they may agree like brothers, and worship me their lord. DICK. The first thing we do, let's kill all the lawyers." Peter Alfke, speaking for himself ;-) ============================= On Mar 9, 5:04 am, "MK" <nos...@please.com> wrote: > I just got an invitation to this years SIlica/Xilinx X-fest. > > I've been to these before and found them useful so I was registering to > attend until I came to this bit: > > I grant Avnet, Inc. (avnet), its affiliates, subsidiaries, assigns, > licensees, and design irrevocable right to use my name, picture, likeness > and/or photograph, and biography information ( collectively the "materials") > in all forms and media now known or hereby developed, and in all manners, > including composite or distorted representations, for marketing, trade, > editorial, and any other purposes whatsoever. I waive any right to approve > any uses that may be created in connection therewith, or the use to which > Materials may be applied. I agree that the Materials, the negatives, and > other originals shall constitute Avnet's sole property, with full right of > disposition in any manner whatsoever. I hereby release, discharge, and agree > to hold harmless Avnet, its affiliates, subsidiaries, assigns, licensees, > and designees, and all persons acting under its permission or anyone from > any and all claims whatsoever in connection with the use of the materials. I > have read the release and am fully familiar with its contents. > > I choked on that so I'll stick with Lattice for another design or two. > > Michael Kellett > > www.mkesc.co.ukArticle: 116474
I thought the solution to this problem might be useful for others. I've just had to fight this problem again after installing ISE9.1 and trying to use it to to compile a project created in 8.2. It is known that the ISE and EDK tools have to be of the same revision for the integration to work properly. In this case I had to delete the xmp file from the project tree and rely on the ability of ISE to pick up previously generated EDK netlist files during build time. That all worked fine, but no EdkBmmFile_bd.bmm file was generated by the bitgen in the end. So, the solution was apparently very simple: add -bm EdkBmmFile.bmm to ngdbuild command line. This can be done in the Translate Properties GUI pane. It seems that bitgen decides whether to generate _bd.bmm or not based on what's in the ncd file. /Mikhail "Steve" <sgfallows@gmail.com> wrote in message news:1166112586.977099.46940@16g2000cwy.googlegroups.com... >I have an XPS/ISE project for a Xilinx Virtex II Pro. The XPS design is > called PPC_DDR and is instantiated on a top level schematic in ISE > (called JTT_DDR). I am unable to get the .bit file to be updated with > the code from the XPS application that is marked for BRAM > initialization. I cannot get ISE to create an _bd.bmm file with > placement information in it. > > XPS created two files: PPC_DDR.bmm and PPC_DDR_stub.bmm, both in > JTT_DDR\PPC_DDR\implementation\. ISE created a file called > edkBmmFile.bmm in the JTT_DDR directory. edkBmmFile.bmm and > PPC_DDR_stub.bmm are identical. I have tried adding either of these > files to the ISE project and get the same result in either case. The > error message listed below is reported and a file called XpsTempBmm.bmm > is created. The XpsTempBmm.bmm file contains only the line "#include > edkBmmFile.bmm" *TWICE*. which seems to be the error and explain the > error message below. > > How am I supposed to get ISE to produced the "placed" version of the > bmm file?? > > Error Message: > --------------------------------------- > NGDBUILD done. > > ERROR:Data2MEM:34 - Duplicate ADDRESS_SPACE or ADDRESS_MAP name usage > 'plb_bram_if_cntlr_1_bram'. > Line #4, File "edkBmmFile.bmm". > ADDRESS_BLOCK plb_bram_if_cntlr_1_bram RAMB16 [0xffffc000:0xffffffff] > ^ > Line #3, File "XpsTempBmm.bmm". > > > FATAL:Data2MEM:43 - Release of unknown memory pointer, 0x04A85520. > Source file "../s/D2BUtil_Data2Bram_impl.c", line number 96. >
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