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
The system have 64 KB memory.And the program is not so large. >Hi, > >So how large is your program and how much memory do you have in your system? > >Göran >Article: 123101
On Aug 16, 3:28 am, "MikeJ" <mi...@fpgaarcade.nospam.com> wrote:
> Thanks Austin, as always.
>
> I couldn't find anything in the documentation which said you couldn't
> directly drive two DCMs using the fast path, in fact Xilinx recommend
> driving the DCMs in parallel to avoid jitter accumulation. More editor
> playing required ....
>
> I can live with this as long as I constrain the net between the IBUFG and
> the DCMs well enough, I have a fair margin on my input bus, the output is
> source-synchronous so I don't care.
>
> If I move the DCMs to the BUFG side (so, IBUFG -> BUFG -> LOGIC + 2 DCMs)
> then I guess I will have to compensate for the BUFG delay in my DCM phase
> set up?
>
> Regards,
> /Mike
>
> "austin" <aus...@xilinx.com> wrote in message
>
> news:f9vr9h$g1q1@cnn.xilinx.com...
>
> > Mike,
>
> > I think perhaps you have figured it out: driving two DCM's from the
> > same IBUFG and a BUFG may not be possible.
>
> > Since you have FPGA_editor open, you should be able to see the direct
> > path (only using IBUFG) to the DCM CLKIN pin. Are you able to place and
> > route this path all by itself without issue? Obviously, this is the
> > "normal" way of doing things, so this should work. Then see if you may
> > add another CLKIN to that net (perhaps there is no way to do this --
> > FPGA_editor will show you the allowed control points....)
>
> > If this is something you must do, and you use a variable phase shift,
> > then the problem will be chip to chip variation. The jump off into
> > regular routing can not be compensated for. As long as you remain
> > without the classic use models, the data sheet specifications apply for
> > worst case phase error.
>
> > Austin
FWIW, I tried your configuration manually in fpga_editor and it works
OK (i.e. dedicated routes to DCMs and BUFG). Below is the delay report
in fpga_editor
Net "$NET_1":
driver - comp.pin "$COMP_3.I", site.pin "B15.I"
1.255ns - comp.pin "$COMP_1.CLKIN", site.pin "DCM_ADV_X0Y2.CLKIN"
1.264ns - comp.pin "$COMP_2.CLKIN", site.pin "DCM_ADV_X0Y3.CLKIN"
0.835ns - comp.pin "$COMP_4.I1", site.pin "BUFGCTRL_X0Y31.I1"
Cheers
Jim
http://home.comcast.net/~jimwu88/tools/
Article: 123102"ted" <ted.boydston@gmail.com> wrote in message news:1187187861.573794.9990@e9g2000prf.googlegroups.com... > Hi, > > So, the next time you are searching for an ASIC, FPGA, or EDA topic, > why not check out http://www.chiphit.com. > > Thanks, > Ted > Hi Ted, That's pretty cool, looks like you put a fair bit of effort into it, it seems to work well! BTW., if the requirement is just to search a single site, e.g. xilinx.com , Google toolbar lets you create a custom search button. You install the toolbar, navigate to xilinx.com, right click in the search box on that page, and choose 'Generate custom search...' . A button now appears on the toolbar. (I think I posted this before, but I was quite pleased to find it!) HTH., Syms.Article: 123103
Hi, Can you do a mb-size on the final .elf file? Göran Bilski "mfgunes" <mfgunes@yahoo.com> wrote in message news:6KudnU_p4fSSvlnbRVn_vw@giganews.com... > The system have 64 KB memory.And the program is not so large. > > > > >>Hi, >> >>So how large is your program and how much memory do you have in your > system? >> >>Göran >> >Article: 123104
"MikeJ" <mikej@fpgaarcade.nospam.com> wrote in message news:n0Twi.6258$ZA.2931@newsb.telia.net... > Thanks Austin, as always. > > I couldn't find anything in the documentation which said you couldn't > directly drive two DCMs using the fast path, in fact Xilinx recommend > driving the DCMs in parallel to avoid jitter accumulation. More editor > playing required .... > > I can live with this as long as I constrain the net between the IBUFG and > the DCMs well enough, I have a fair margin on my input bus, the output is > source-synchronous so I don't care. > > If I move the DCMs to the BUFG side (so, IBUFG -> BUFG -> LOGIC + 2 DCMs) > then I guess I will have to compensate for the BUFG delay in my DCM phase > set up? > > Regards, > /Mike > Hi Mike, This could be a job for 'Directed routing constraints'. In FPGA editor click Tools -> Directed Routing Constraints . You can select nets in your design that are routed as you want and get the tool to spit out a load of gobbledegook that you can cut-n-paste into your UCF file. This ensures (in the Xilinx software sense of the word) that your routing is the same every time. HTH., Syms.Article: 123105
Now I better understand. Number of wires grows faster than number of logic, though the "growth rate" in state-of-the-art FPGA device is not that high. Thank you for providing a good example.Article: 123106
Size of the .elf file is 23 KB >Hi, > >Can you do a mb-size on the final .elf file? > >Göran Bilski > >"mfgunes" <mfgunes@yahoo.com> wrote in message >news:6KudnU_p4fSSvlnbRVn_vw@giganews.com... >> The system have 64 KB memory.And the program is not so large. >> >> >> >> >>>Hi, >>> >>>So how large is your program and how much memory do you have in your >> system? >>> >>>Göran >>> >> > > >Article: 123107
Have you enabled "Mark to initialize BRAM" on multiple software applications in XPS? Can you share some more information on your system and your settings? Göran "mfgunes" <mfgunes@yahoo.com> wrote in message news:m6edna5JUeCByFnbRVn_vw@giganews.com... > Size of the .elf file is 23 KB > > >>Hi, >> >>Can you do a mb-size on the final .elf file? >> >>Göran Bilski >> >>"mfgunes" <mfgunes@yahoo.com> wrote in message >>news:6KudnU_p4fSSvlnbRVn_vw@giganews.com... >>> The system have 64 KB memory.And the program is not so large. >>> >>> >>> >>> >>>>Hi, >>>> >>>>So how large is your program and how much memory do you have in your >>> system? >>>> >>>>Göran >>>> >>> >> >> >> > >Article: 123108
Okay, meanwhile I got the DDR model implemented in my design. The testbench compiles without errors and warnings and...the DDR model does not work. In fact every write access is accepted. But when it comes to read accesses an error occurs. I can see in the waveform that the requested data appears on the DDR_DQ bus and is transmitted to the DDR controller. But it never appears on the PLB bus. The following message is written in the transcript: ** Warning: PLB IPIF data phase timeout assertion.... Addressed Target did not respond! # Time: 515160 ns Iteration: 4 Instance: /xup_morpheus7_wrapper/ xup_morpheus7_1/ddr_256mb_32mx64_rank1_row13_col10_cl2_5/ ddr_256mb_32mx64_rank1_row13_col10_cl2_5/wo_ecc/plb_ipif_i/ i_slave_attachment But when I take a look at the waveform the signals of the master/slave- protocol look fine to me. The DDR controller accepts the read request from my design. And after some time the the acknowledge signal is assigned (bus2ip_mstrdack = '1' and bus2ip_mstlastack = '1'). So even the time limit which causes the message is exceeded the DDR controller handles the read request. But the transmitted data is always 0x00000000. Does anybody know, how to solve this problem? Is it a timing issue? I use the SG75 configuration for my model. The parameters are below or equal to the parameters of the Kingston module. I think this should work, shouldn't it? I also created the RAM module by myself. So I did not use the DIMM file parameters. I will try to compile a complete DIMM instead of 8 single RAM modules. But I don't think that this will change a lot since I copied the signals assignments from the DIMM file.Article: 123109
In EDK, please set your STDIN and STDOUT to whatever RS232 UART's that you have. -- parag On Aug 16, 1:00 am, kobela...@gmail.com wrote: > what's wrong with following error???? > > [root@184pc140 bin]# ./mb-gcc hello.c > /home/devel/uclinux/bin/mb_tools/bin/../lib/gcc/microblaze/ > 3.4.1/../../../../microblaze/lib/libc.a(write.o): In function `write': > write.o(.text+0x34): undefined reference to `outbyte' > write.o(.text+0x58): undefined reference to `outbyte' > /home/devel/uclinux/bin/mb_tools/bin/../lib/gcc/microblaze/ > 3.4.1/../../../../microblaze/lib/libc.a(read.o): In function `read': > read.o(.text+0x2c): undefined reference to `inbyte' > collect2: ld returned 1 exit statusArticle: 123110
Hi I am designing two boards with virtex 4 fx devices fitted. They will stack one on top of the other using a board to board connector. The spacing between boards is about 20mms. Is it critical the type of connector that I use to connect the MGT links between the boards. Do I need one of these fancy 50 ohmn connectors or can I get away with something else? Is there a way to simulate the effects that the connector will have? Cheers JonArticle: 123111
Hi all, I need to implement a SCILAB matrix code into a FPGA (vhdl or verilog code , use dsp block, or any others solutions). => Any help is highly appreciated (exemple, user guide, etc...) !. => Do you have any information to the FPGA choice (Altera, Xilinx, Lattice) (methods, tools, etc...) Thanks in advance, bhbArticle: 123112
On 16 Aug., 17:12, "maxascent" <maxasc...@yahoo.co.uk> wrote: > Is it critical the type of connector that I > use to connect the MGT links between the boards. yes > Do I need one of these fancy 50 ohmn connectors no. > or can I get away with something else? Yes, but not just anything random. The impedance must match the impedance of your board routing. > Is there a > way to simulate the effects that the connector will have? Yes. Manufacturers like samtec publish electrical models of their connectors. You can get models of the FPGA-pins from Xilinx. Read this: http://www.amazon.com/High-Speed-Digital-Design-Handbook-Black/dp/0133957241/ref=sr_1_1/105-2062477-6600447?ie=UTF8&s=books&qid=1187280826&sr=8-1 Kolja SulimmaArticle: 123113
To get a meaningfull answer you should tell us: - what operations are involved? Addition of 1x1 matrices? Inversion of huge matrices? - is there a performance constraint? If not, I suggest that you compile SCILAB for PowerPC and run in on a Virtex-4 FX. Problem solved. Kolja Sulimma On 16 Aug., 17:42, "bhb" <bhb...@yahoo.fr> wrote: > Hi all, > > I need to implement a SCILAB matrix code into a FPGA (vhdl or verilog code , > use dsp block, or any others solutions). > => Any help is highly appreciated (exemple, user guide, etc...) !. > => Do you have any information to the FPGA choice (Altera, Xilinx, Lattice) > (methods, tools, etc...)Article: 123114
kron wrote:
> My problem is, that I get bullshit from the registers.
let's have a look at the synthesis warnings:
Warning: Design contains 34 input pin(s) that do not drive logic
Warning: No output dependent on input pin "START
Warning: No output dependent on input pin "RW_N
Warning: No output dependent on input pin "DATA_INPUT[0]
...
Warning: No output dependent on input pin "DATA_INPUT[31]
Consider running a vhdl sim to debug this controller.
-- Mike Treseler
Article: 123115Hi I was using 'define in my verilog file, while trying to compile the code using Xilinx ISE 7.1 I was getting error ? Could anyone please help me in this regard Rgds bijoyArticle: 123116
On 16 Aug, 17:36, bijoy <pbi...@rediffmail.com> wrote: > Hi I was using 'define in my verilog file, while trying to compile the code using Xilinx ISE 7.1 I was getting error ? > > Could anyone please help me in this regard `define or 'define? Make sure you're using the correct tick. Also, please post the exact error message it gave, and any code that might come before the error. Cheers, JonArticle: 123117
>>
> Hi Mike,
> This could be a job for 'Directed routing constraints'. In FPGA editor
> click Tools -> Directed Routing Constraints . You can select nets in your
> design that are routed as you want and get the tool to spit out a load of
> gobbledegook that you can cut-n-paste into your UCF file. This ensures (in
> the Xilinx software sense of the word) that your routing is the same every
> time.
> HTH., Syms.
Jim, thanks very much for trying it, I managed to get the same result. I
moved the locs on the DCM from 0,1 to 2,3 and removed a skew constraint on
this clock which seems to be confusing the tools.
Now I get
driver - comp.pin "laclk.I", site.pin "A10.I"
0.749ns - comp.pin "bufg_laclk.I0", site.pin "BUFGCTRL_X0Y25.I0"
1.213ns - comp.pin "/snip/DCM_ADV_INST.CLKIN", site.pin
"DCM_ADV_X0Y5.CLKIN"
1.222ns - comp.pin "/snip/DCM_ADV_INST.CLKIN", site.pin
"DCM_ADV_X0Y4.CLKIN"
Syms, excellent idea about the direct routine, it works nicely. Now I know
it won't move again. I have also added some other constraints so I can pick
it up if it does go wrong.
Thanks for the help,
Cheers,
Mike
Article: 123118um, of course that should say "directed routing" rather than "direct routine" Must learn to type... "MikeJ" <mikej@fpgaarcade.nospam.com> wrote in message news:RP%wi.6289$ZA.3062@newsb.telia.net... >>> >> Hi Mike, >> This could be a job for 'Directed routing constraints'. In FPGA editor >> click Tools -> Directed Routing Constraints . You can select nets in your >> design that are routed as you want and get the tool to spit out a load of >> gobbledegook that you can cut-n-paste into your UCF file. This ensures >> (in the Xilinx software sense of the word) that your routing is the same >> every time. >> HTH., Syms. > > Jim, thanks very much for trying it, I managed to get the same result. I > moved the locs on the DCM from 0,1 to 2,3 and removed a skew constraint on > this clock which seems to be confusing the tools. > > Now I get > driver - comp.pin "laclk.I", site.pin "A10.I" > 0.749ns - comp.pin "bufg_laclk.I0", site.pin "BUFGCTRL_X0Y25.I0" > 1.213ns - comp.pin "/snip/DCM_ADV_INST.CLKIN", site.pin > "DCM_ADV_X0Y5.CLKIN" > 1.222ns - comp.pin "/snip/DCM_ADV_INST.CLKIN", site.pin > "DCM_ADV_X0Y4.CLKIN" > > Syms, excellent idea about the direct routine, it works nicely. Now I know > it won't move again. I have also added some other constraints so I can > pick it up if it does go wrong. > Thanks for the help, > Cheers, > Mike >Article: 123119
> What is your expected maximum edge count, in that 500us ? Depends on the pulse in question. I've implemented five different variants utilizing different techniques. The first is a "brute force" BRAM-based approach. The other variants use a-priori knowledge of the pulse patterns to implement delays using counters, pulse lengths, etc. It's a good problem. It is clear that low resource solutions are possible (and desirable) if pulses are relatively cyclic and this knowledge can be coded into the logic from the start. The case of a randomly changing pulse with a random number of transitions per unit of time is probably one that almost requires a BRAM buffer approach. Thanks for your suggestions. I think I have a couple of low-resource solutions that work well now. Valuable BRAM resources have been preserved for the rest of the design. -MArticle: 123120
"maxascent" <maxascent@yahoo.co.uk> wrote in message news:o5Wdnb8wwOfp9FnbRVn_vgA@giganews.com... > Hi > > I am designing two boards with virtex 4 fx devices fitted. They will stack > one on top of the other using a board to board connector. The spacing > between boards is about 20mms. Is it critical the type of connector that I > use to connect the MGT links between the boards. Do I need one of these > fancy 50 ohmn connectors or can I get away with something else? Is there a > way to simulate the effects that the connector will have? > > Cheers > > Jon > First of all at what speed are you going to be running it? I have a design running multiple 3.36 Gbps links over a standard cPCI connector without any problem. I would say use something with small pitch and enclose each of your differential pairs in between GND pins and you will be fine... Ideally you'd need at least 3 rows of pins to fully enclose each of the pairs, but I am pretty sure it will work even with a single row connector. With such a short link there is a lot of margin. /MikhailArticle: 123121
Thanks Alan, if(up='1' and count_int/=max)then ... elsif( down='1'and count_int/=0) then ... got rid of the warnings and a considerable numbers of slices. The only difference I can see is that my start_value had better be "in range" which is OK for my aplication. Brad "Alan Nishioka" <alan@nishioka.com> wrote in message news:1187178437.624159.196390@i38g2000prf.googlegroups.com... > Are you sure you need > (greater than) operator here? > This requires a subtraction and a carry chain, so your counter needs > two carry chains and won't pack. > Can you use not-equal instead? > > (This also applies to < (less than) operator) > > Alan Nishioka > > > On Aug 14, 6:17 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> > wrote: >> What does this "PACKER" warning >> mean? >> >> Lut _ driving carry _ can not >> be packed with the carry due >> to conflict with the common >> signal requirement between Lut >> inputs and the Carry DI/MAND pins. >> This would result in an extra Lut >> for a feedthrough. >> >> Here is the VHDL code: >> >> count_int_proc:process(clk) >> begin >> if(clk'event and clk='1')then >> if(reset='1')then >> count_int <= start_value; >> elsif( enable='1') then >> if(up='1' and count_int<max)then >> count_int<=count_int+1; >> elsif( down='1'and count_int>0) then >> count_int<=count_int-1; >> end if; >> end if; >> end if; >> end process; >> >> Thanks, >> Brad Smallridge >> AI Vision > >Article: 123122
Hi Andy, I could see where this might save a lot of hardware by using the carry flag, however, all my variables in my example were std_logic_vector inputs and the max need not be 2**N-1. Brad Smallridge > If you use an integer subtype for count_int and check for > "not(count_int - 1 < 0)" or "not (count_int + 1 > max)" then the carry > out of the incrementor and decrementor can be shared with the > respective comparison (and/or similarly optimized). That's also > assuming max = 2**N-1 for positive integer N. Don't try this with SLV > or UNSIGNED. > > Andy >Article: 123123
I hate to sound like a broken record, but: Huffman run-length encoding was invented exactly for such a problem, and it has proven its effectiveness in fax machines the world over. Peter Alfke On Aug 16, 10:41 am, m <martin.use...@gmail.com> wrote: > > What is your expected maximum edge count, in that 500us ? > > Depends on the pulse in question. > > I've implemented five different variants utilizing different > techniques. The first is a "brute force" BRAM-based approach. The > other variants use a-priori knowledge of the pulse patterns to > implement delays using counters, pulse lengths, etc. > > It's a good problem. It is clear that low resource solutions are > possible (and desirable) if pulses are relatively cyclic and this > knowledge can be coded into the logic from the start. The case of a > randomly changing pulse with a random number of transitions per unit > of time is probably one that almost requires a BRAM buffer approach. > > Thanks for your suggestions. I think I have a couple of low-resource > solutions that work well now. Valuable BRAM resources have been > preserved for the rest of the design. > > -MArticle: 123124
Thanks Mike, I am using this code to adjust a value for a menu display and I have pushbuttons controlling its value. One pb for up and another for down. Having separate up and down inputs was the first thing that occurred to me, although that isn't usually how an up/down counter is ported, is it. The enable is controlled by the "cursor" position. Brad Smallridge Ai Vision "Mike Treseler" <mike_treseler@comcast.net> wrote in message news:5ih1tfF3pv0r9U1@mid.individual.net... > Brad Smallridge wrote: >> What does this "PACKER" warning >> mean? > > The fitter feels guilty about one of the LUTs it used. > It's just a warning. > Unless I were short on LUTs I would > not spend time on it. > > The code looks ok to me. > You could combine the up/down input. > > > -- Mike Treseler
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z