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
glen herrmannsfeldt wrote: > Not so long ago, I was considering a project for genomics that > needs about 1e18 six bit add/subtract operations per day. > I figured out that it could be done with about 2000 S3E devices, > though so far no interest in building one. at this level, maybe a finely tuned and optimised MMX/SSE/SSE2/whatever code would do the trick, using 8-bit chunks in 64, 128 or 256-bits wide words... and it would be future-proof, as the x86 (or whatever arch of the day is) could be upgraded to faster/lower power/more core hardware. Yeah i know, it's software and it's not sexy... but if it's sufficiently simple, it can be coded with GCC intrinsics such as in this file : http://ygdes.com/sources/lm98/def64.h just my 0,02 bits of entropy :-) > -- glen yg -- http://ygdes.com / http://yasep.orgArticle: 151201
Hi Brian, Thanks a lot for your answer! > > If "tb.exe" is the name of the generated ISIM executable, >command line options can be listed at the command prompt with: >tb -h > Thanks for the tip! However, my problem lies elsewhere, so hope I can clarify it better this time :) Namely: while I was working through the ISE GUI, I always assumed that I should always run first "XST - Synthesize", and only then I could run "Simulate Behavioral Model" ... Likewise, after that I should likewise run "Implement Design" (all stages) first before "Simulate Post-Place & Route Model". However, after trying a bit on the command line, I realized that `xst` actually generates an .ngc netlist file (I guess, the "RTL schematic") - however, when we call `fuse` to generate an ISIM .exe, as in: >:: >fuse -prj isim_rtl.prj -work work=work.isim -o tb.exe -top >testbench > .. `fuse`, in fact, demands only the list of source files in the .prj file (as also illustrated in your code) - it does not require a compiled `ngc` file beforehand at all! This leads me to believe, that a `fuse` command like the above is what corresponds to "Simulate Behavioral Model" in the ISE GUI (and of course, in the GUI, you can just add files to your project - and then go directly to "Simulate Behavioral Model", without doing 'XST - Synthesize' beforehand). So, if the above `fuse` command corresponds to "Simulate Behavioral Model" - what would be the `fuse` command corresponding to "Simulate Post-Place & Route Model"? I'm guessing, first a 'compiled' ""Native Generic Database" ngd file (netlist?) is needed, as output of `xst` -> `ngdbuild` -> `map` -> `par` pipeline; but I don't see `fuse` options that accept this kind of file as an argument? The only thing stated in http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/plugin_ism.pdf is "It is also possible to instruct the simulator to use the correct timing delays from the SDF file.", but this is an option for the simulator executable, not for `fuse` itself... and still, the place & route .ngd file figures nowhere; I'm not sure if this .sdf file replaces it? Or maybe - `fuse` is supposed to read .ngd files automatically, in the directory where the source files are located ?! Well, hope I can get some comments back on this, Thanks - and cheers! --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151202
the thread returned interesting thanks all !Article: 151203
whygee <yg@yg.yg> wrote: (after I wrote) >> Not so long ago, I was considering a project for genomics that >> needs about 1e18 six bit add/subtract operations per day. >> I figured out that it could be done with about 2000 S3E devices, >> though so far no interest in building one. > at this level, maybe a finely tuned and optimised MMX/SSE/SSE2/whatever > code would do the trick, using 8-bit chunks in 64, 128 or 256-bits > wide words... and it would be future-proof, as the x86 (or whatever > arch of the day is) could be upgraded to faster/lower power/more core > hardware. At (about) 1e5 seconds/day, I need 1e13/second. At 1GHz, that is 1e4 per clock cycle. No, there are no 80000 bit registers in MMX or SSE. -- glenArticle: 151204
In article <ilnebt$tm9$1@news.eternal-september.org>, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >whygee <yg@yg.yg> wrote: > >(after I wrote) >>> Not so long ago, I was considering a project for genomics that >>> needs about 1e18 six bit add/subtract operations per day. >>> I figured out that it could be done with about 2000 S3E devices, >>> though so far no interest in building one. > >> at this level, maybe a finely tuned and optimised MMX/SSE/SSE2/whatever >> code would do the trick, using 8-bit chunks in 64, 128 or 256-bits >> wide words... and it would be future-proof, as the x86 (or whatever >> arch of the day is) could be upgraded to faster/lower power/more core >> hardware. > >At (about) 1e5 seconds/day, I need 1e13/second. At 1GHz, >that is 1e4 per clock cycle. No, there are no 80000 bit >registers in MMX or SSE. No, but getting hold of a hundred PCs (which will do four SSE operations per clock cycle, so about sixty six-bit add/subtracts, and run at 2.5GHz with four cores) is not a difficult task. If you can partition the job over 2000 FPGAs, you can probably partition it over 100 PCs. TomArticle: 151205
Thomas Womack wrote: > No, but getting hold of a hundred PCs (which will do four SSE > operations per clock cycle, so about sixty six-bit add/subtracts, and > run at 2.5GHz with four cores) is not a difficult task. If you can > partition the job over 2000 FPGAs, you can probably partition it over > 100 PCs. And the PC farm can be easily repurposed, upgraded, etc. (even though i don't like them, but i see the business case) > Tom yg -- http://ygdes.com / http://yasep.orgArticle: 151206
sdaau wrote: > > So, if the above `fuse` command corresponds to "Simulate Behavioral Model" > Note that Fuse does not _run_ the simulation, it just builds a stand alone executable, which then must be run to produce simulation results. > - what would be the `fuse` command corresponding to > "Simulate Post-Place & Route Model"? I've never done that with ISIM, so I can't provide a specific example. In general, Netgen produces a structural VHDL/Verilog model from the implementation files, which is then simulated along with an .sdf file to backannotate routing delays. See "design flow" figures 2-2 and 2-9 of: http://www.xilinx.com/itp/xilinx92/books/docs/dev/dev.pdf So, from your original post: > > Running Fuse ... > Compiling project file "./mytest_tbw_beh__vlog.prj" > ... > Building mytest_tbw_isim_beh.exe > Running ISim simulation engine ... > The "compiling" bit gives you the name of the ISIM project file; so if you look at this same log, but for a post P&R simulation run, you should find another .prj file that'll give you the structural source file being compiled for the post P&R simulation. See pages 49-51 of UG660 11v3 "Running a Timing Simulation of a Verilog Design From the Command Line" http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/plugin_ism.pdf UG682 is a good ISIM intro: http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/ug682.pdf HTH, BrianArticle: 151207
Hi Brian, Thanks again for the prompt answer! > > In general, Netgen produces a structural VHDL/Verilog model from the >implementation files, which is then simulated along with an .sdf file >to backannotate routing delays. > Thanks for that - `netgen` was the key to my misunderstanding... For the benefit of noobs elsewhere :) , I shall quote "Command Line Tools User Guide", http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/devref.pdf: > The flow type that NetGen runs is based on the input design file > (NGC, NGD, or NCD). The following table shows the output file > types, based on the input design files: ... When performing > timing simulation, you must specify the type of netlist you want > to create: Verilog or VHDL. In addition to the specified netlist, > NetGen also creates an SDF file as output. The output Verilog and > VHDL netlists contain the functionality of the design and the SDF > file contains the timing information for the design. By the way, I experimented a bit with querying process IDs in Linux, and could capture most of the command lines issued by ISE when running particular commands. So, given that the reference point is after "Cleanup Project Files": * Executing "Simulate Behavioral Model" runs, simply, through the `fuse` -> `_isim.exe` flow: fuse -ise /media/testsynthdir/design-twb.ise -intstyle ise -incremental -lib unisims_ver -lib xilinxcorelib_ver -o XMyTopLevel_twb_isim_beh.exe -prj XMyTopLevel_twb_beh.prj -top XMyTopLevel_twb -top glbl /XMyTopLevel_twb_isim_beh.exe -intstyle ise -ipchost localhost -ipcport 56480 .. where ..._beh.prj contains all respective source files, plus glbl.v if Verilog is used, as in: ---- vhdl work "../XMyTopLevel.vhd" vhdl work "../XMyTopLevel_twb.vhd" .. verilog work "/path/to/Xilinx92i/verilog/src/glbl.v" ---- * Executing "Simulate Post-Place & Route Model", goes through the `xst` -> `xst` -> `map` -> `par` -> `trce` -> `netgen` -> `fuse` -> `_isim.exe` sequence: xst -ise /media/testsynthdir/design-twb.ise -intstyle ise -ifn XMyTopLevel.xst -ofn XMyTopLevel.syr xst -ifn /media/testsynthdir/XMyTopLevel.xst -ofn ofnNtrc -ise /media/testsynthdir/design-twb.ise -XstNtrc ngdbuild -ise /media/testsynthdir/design-twb.ise -intstyle ise -dd _ngo -nt timestamp -i -p xc3s50a-tq144-5 XMyTopLevel.ngc XMyTopLevel.ngd map -ise /media/testsynthdir/design-twb.ise -intstyle ise -p xc3s50a-tq144-5 -cm area -pr b -k 4 -c 100 -o XMyTopLevel_map.ncd XMyTopLevel.ngd XMyTopLevel.pcf par -ise /media/testsynthdir/design-twb.ise -w -intstyle ise -ol std -t 1 XMyTopLevel_map.ncd XMyTopLevel.ncd XMyTopLevel.pcf trce -ise /media/testsynthdir/design-twb.ise -intstyle ise -e 3 -s 5 -xml XMyTopLevel XMyTopLevel.ncd -o XMyTopLevel.twr XMyTopLevel.pcf netgen -ise /media/testsynthdir/design-twb.ise -intstyle ise -s 5 -pcf XMyTopLevel.pcf -rpw 100 -tpw 0 -ar Structure -tm XMyTopLevel -insert_pp_buffers false -w -dir netgen/par -ofmt vhdl -sim XMyTopLevel.ncd XMyTopLevel_timesim.vhd fuse -ise /media/testsynthdir/design-twb.ise -intstyle ise -incremental -lib unisims_ver -o XMyTopLevel_twb_isim_par.exe -prj XMyTopLevel_twb_par.prj -top XMyTopLevel_twb /XMyTopLevel_twb_isim_par.exe -sdfmax /UUT/=netgen/par/XMyTopLevel_timesim.sdf -sdfroot /UUT -intstyle ise -ipchost localhost -ipcport 37824 .. where ..._par.prj contains only entries for the workbench, and a _timesim.vhd: ---- vhdl work "netgen/par/XMyTopLevel_timesim.vhd" vhdl work "../XMyTopLevel_rdwr_tbw.vhd" ---- So, in brief, I guess it could be said: for behavioral simulation, `fuse` can simply operate on the source files directly, to generate an _isim.exe; for post-place and route simulation, `fuse` needs a timing model (and the _isim.exe will need an .sdf file) generated previously by `netgen` (which operates on netlist/design files previously obtained by `map` & `par`...) Note also that: * `fuse` may call `vhpcomp` which in turn may call `g++` * funnily enough, I couldn't obtain a command line for "Cleanup Project Files" :) Hope this is close to the correct understanding, else I'd love to hear a correction, Cheers! --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151208
Hello, Has anyone had any experience working with this particular development board? (HTG-V5-PCIe) I am trying to get the DMA to DDR2 interface up and running but there's really not much of an example design to work from. Believe Xilinx has XAPP859, but it is specific to the ML555 Xilinx board. Thanks.Article: 151209
Here's a Xilinx option for $89. FPGA configuration, Flash programming, hardware debugging, and MicroBlaze debugging are all available through the on-board USB-JTAG circuit using iMPACT, ChipScope, and SDK. I'm not aware of a Windows .NET driver for it. www.em.avnet.com/s6microboard Bryan On Mar 14, 6:38=A0pm, "Abby Brown" <abbybr...@charter.net> wrote: > Hi, > > Does someone produce a cheaper and simpler substitute for > Altera's Cyclone III starter board? =A0It needs to connect to a > laptop to download configuration and test cases and upload > results (ICT). =A0A driver that connects to Windows .Net would be > ideal. > > Thanks, > GaryArticle: 151210
Hello, There are lots of reasons why your simulations might not match your results in hardware, but it might be easiest to use Chipscope to look at fifo counts and flags during your tests to see what's really going on. This of course assumes that using Chipscope is an option for you (you have internal memory to spare, access to JTAG, etc.). Regards, -- Mike Shogren Director of FPGA Development Epiq Solutions http://www.epiq-solutions.comArticle: 151211
Hi, A newbie's question, in the following code: module reg_file ( input wire clk, input wire wr_en, input wire [1:0] w_addr, r_addr, input wire [7:O] w_data, output wire [7:Ol r_data ) reg [7:Ol array_reg [2**1:0] ; always @(posedge clk) if (wr_en) array_reg [w_addrl <= w_data; assign r_data = array_reg [r_addr]; why is the writing done sequentially and the reading purely combinational? That is writing inside an always activated on the front edge of clk and reading in a continuous assignment. Thanks --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151212
>Hello, > >There are lots of reasons why your simulations might not match your >results in hardware, but it might be easiest to use Chipscope to look >at fifo counts and flags during your tests to see what's really going >on. This of course assumes that using Chipscope is an option for you >(you have internal memory to spare, access to JTAG, etc.). > >Regards, >-- >Mike Shogren >Director of FPGA Development >Epiq Solutions >http://www.epiq-solutions.com > > Yes, i do have access to Chipscope and i have been using it all along, but i have not been able to capture the moment where everything goes haywire (my fifos overrun). Anyway, i'll try something tomorrow and will post the update. thanks --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151213
On Mar 15, 10:26=A0am, "sebas" <tanarnelinistit@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.com> wrote: > Hi, > > A newbie's question, in the following code: > > module reg_file > ( > input wire clk, > input wire wr_en, > input wire [1:0] w_addr, r_addr, > input wire [7:O] w_data, > output wire [7:Ol r_data > ) > > reg [7:Ol array_reg [2**1:0] ; > always @(posedge clk) > =A0 =A0 =A0 =A0 if (wr_en) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 array_reg [w_addrl <=3D w_data; > assign r_data =3D array_reg [r_addr]; > > why is the writing done sequentially and the reading purely combinational= ? > That is writing inside an always activated on the front edge of clk and > reading in a continuous assignment. > > Thanks =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Because the designer wanted the read to be asynchronous? Ed McGettigan -- Xilinx Inc.Article: 151214
I wouldnt of thought it should really matter what board you have, the fpga internals will be the same. Its just a matter of getting each piece of IP (DDR2, DMA, PCIE) working. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151215
>On Mar 15, 10:26=A0am, "sebas" ><tanarnelinistit@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.com> wrote: >> Hi, >> >> A newbie's question, in the following code: >> >> module reg_file >> ( >> input wire clk, >> input wire wr_en, >> input wire [1:0] w_addr, r_addr, >> input wire [7:O] w_data, >> output wire [7:Ol r_data >> ) >> >> reg [7:Ol array_reg [2**1:0] ; >> always @(posedge clk) >> =A0 =A0 =A0 =A0 if (wr_en) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 array_reg [w_addrl <=3D w_data; >> assign r_data =3D array_reg [r_addr]; >> >> why is the writing done sequentially and the reading purely combinational= >? >> That is writing inside an always activated on the front edge of clk and >> reading in a continuous assignment. >> >> Thanks =A0 =A0 >> >> --------------------------------------- =A0 =A0 =A0 =A0 >> Posted throughhttp://www.FPGARelated.com > >Because the designer wanted the read to be asynchronous? > >Ed McGettigan >-- >Xilinx Inc. > Lol, good answer. Let me rephrase that, then: is this a usual practice: the writing to be synchronous and the reading to be asynchronous? Can they both be asynchronous? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151216
On Mar 15, 11:05=A0pm, "andreiseb" <andrei.jacota@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > >On Mar 15, 10:26=3DA0am, "sebas" > ><tanarnelinistit@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.com> wrote: > >> Hi, > > >> A newbie's question, in the following code: > > >> module reg_file > >> ( > >> input wire clk, > >> input wire wr_en, > >> input wire [1:0] w_addr, r_addr, > >> input wire [7:O] w_data, > >> output wire [7:Ol r_data > >> ) > > >> reg [7:Ol array_reg [2**1:0] ; > >> always @(posedge clk) > >> =3DA0 =3DA0 =3DA0 =3DA0 if (wr_en) > >> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 array_reg [w_addrl <= =3D3D w_data; > >> assign r_data =3D3D array_reg [r_addr]; > > >> why is the writing done sequentially and the reading purely > combinational=3D > >? > >> That is writing inside an always activated on the front edge of clk an= d > >> reading in a continuous assignment. > > >> Thanks =3DA0 =3DA0 > > >> --------------------------------------- =3DA0 =3DA0 =3DA0 =3DA0 > >> Posted throughhttp://www.FPGARelated.com > > >Because the designer wanted the read to be asynchronous? > > >Ed McGettigan > >-- > >Xilinx Inc. > > Lol, good answer. Let me rephrase that, then: is this a usual practice: t= he > writing to be synchronous and the reading to be asynchronous? Can they bo= th > be =A0asynchronous? =A0 =A0 =A0 =A0 =A0 > then it would not be a register, it would be a wire :) think of how a flipflop works -LasseArticle: 151217
On Tue, 15 Mar 2011 17:05:38 -0500, "andreiseb" wrote: >is this a usual practice: the >writing to be synchronous and the reading to be asynchronous? Can they both >be asynchronous? Yes, but only if your synthesis tool and target technology support latches or other memory elements that implement such functionality. The phrase "rare as rocking-horse shit" springs to mind. It used to be fairly common, but it's generally frowned upon these days in FPGA-land. -- Jonathan BromleyArticle: 151218
On Mar 15, 3:05=A0pm, "andreiseb" <andrei.jacota@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > >On Mar 15, 10:26=3DA0am, "sebas" > ><tanarnelinistit@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.com> wrote: > >> Hi, > > >> A newbie's question, in the following code: > > >> module reg_file > >> ( > >> input wire clk, > >> input wire wr_en, > >> input wire [1:0] w_addr, r_addr, > >> input wire [7:O] w_data, > >> output wire [7:Ol r_data > >> ) > > >> reg [7:Ol array_reg [2**1:0] ; > >> always @(posedge clk) > >> =3DA0 =3DA0 =3DA0 =3DA0 if (wr_en) > >> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 array_reg [w_addrl <= =3D3D w_data; > >> assign r_data =3D3D array_reg [r_addr]; > > >> why is the writing done sequentially and the reading purely > combinational=3D > >? > >> That is writing inside an always activated on the front edge of clk an= d > >> reading in a continuous assignment. > > >> Thanks =3DA0 =3DA0 > > >> --------------------------------------- =3DA0 =3DA0 =3DA0 =3DA0 > >> Posted throughhttp://www.FPGARelated.com > > >Because the designer wanted the read to be asynchronous? > > >Ed McGettigan > >-- > >Xilinx Inc. > > Lol, good answer. Let me rephrase that, then: is this a usual practice: t= he > writing to be synchronous and the reading to be asynchronous? Can they bo= th > be =A0asynchronous? =A0 =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com- Hide quoted text - > > - Show quoted text - A register file is basically an array of registers (aka flip/flops) with a defined width and depth. As an example you could take 128 registers and define them as 8 bits wide and 16 deep. This can define in Verilog like this: reg [7:0] my_reg_file [3:0] The write to the register file must be synchronous, after all they are registers and they have to save state. In theory it would be possible to create an asynchronous write, but this is comp.arch.fpga and any attempt to do so in an FPGA would be a big mistake. The "read' isn't really a read, but a multiplexer selection of a single register within the array. In the case of the above example this would be a eight 16-to-1 mux with 4 select lines. The address to data would be combinatorial (aka asynchronous), but it would also include a synchronous path for the clock-to-out from the registers in the array. Complicating the asynchronous vs synchronous description of the access is that the read address would have been generated by something synchronous and the data out will likely be stored in something synchronous. So the label is really in the eye of the beholder. Ed McGettigan -- Xilinx Inc.Article: 151219
> > Yes, i do have access to Chipscope and i have been using it all along, but > i have not been able to capture the moment where everything goes haywire > (my fifos overrun). Anyway, i'll try something tomorrow and will post the > update. > If you can't "catch it in the act" then you may need to write some additional debug logic to help, and then add the debug signals to Chipscope as well. But, sounds like you are on the right track and hopefully you make some progress with the additional testing. Hopefully your build times are not terribly long. -- Mike Shogren Director of FPGA Development Epiq Solutions http://www.epiq-solutions.comArticle: 151220
>Hello, > >There are lots of reasons why your simulations might not match your >results in hardware, but it might be easiest to use Chipscope to look >at fifo counts and flags during your tests to see what's really going >on. This of course assumes that using Chipscope is an option for you >(you have internal memory to spare, access to JTAG, etc.). > >Regards, >-- >Mike Shogren >Director of FPGA Development >Epiq Solutions >http://www.epiq-solutions.com > Two points regarding Xilinx FIFOs, assuming that you are generating them with CoreGen: 1. There are lots of flags available to trigger on in ChipScope, e.g. 'Full'. You may need a KEEP attribute to use it in ChipScope. 2. Depending on whether your FIFOs ar common-clock or not, and which version of ISE you are using, the FIFO behavioural model may be slightly wrong. The structural models seem to be good, though. See, for instance, http://www.xilinx.com/support/answers/20414.htm If you have home-brewed your FIFO, stop now, and use CoreGen! --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151221
>If you have home-brewed your FIFO, stop now, and use CoreGen! I dont think you can say that you shouldn't use your own FIFO. From my point of view I have used my own now for quite a while and haven't had any problems. CoreGen is quite a good product but I find it a but of a pain to have to regenerate if I just want to change one thing. I would rather have a piece of verilog code that I can just instantiate a let the synthesizer work out how to create it. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151222
On Mar 14, 8:46=A0pm, Kolja Sulimma <ksuli...@googlemail.com> wrote: > On 13 Mrz., 01:46, rickman <gnu...@gmail.com> wrote: > > > since a bad bitstream has potential of frying an FPGA. > > This argument is invalid. > > You can fry an FPGA with VDHL and vendor synthesis software. > This has been demonstrated at the FPL conference a decade ago. That is a silly statement. It doesn't matter if there are other ways to fry a part. The point is that the vendors exert control over the design software so that they have control over this sort of problem. It doesn't matter if they prevent you 100% from doing damage to the chips. They take responsibility if you are using their tools. > I guess the truth is closer to this argument: documenting the > bitstream format > is a lot of work and is likely to create only very few additional > revenue > from customer that are rather support intensive so it simply isn't > worthwhile for > the vendors. > > I believe that documenting LUT content locations in the bitstream > would be a good > compromise. It is relatively easy to document and use and not much can > go wrong > and it has a decent amount of applications where it is useful. > OTOH: The introduction of SRL16 made it easy to support LUT-reloading > explicitely in the HDL. LUT content is also very easy to reverse engineer. Everything about the CLB is easy to reverse engineer since the structure is regular and repeated. The only hard part is all the little bits and pieces around the edges. BTW, SRL16 is a Xilinx specific feature. I have been assuming we are talking about the process in general. RickArticle: 151223
On Mar 14, 9:28=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Mar 14, 5:46=A0pm, Kolja Sulimma <ksuli...@googlemail.com> wrote: > > > > > On 13 Mrz., 01:46, rickman <gnu...@gmail.com> wrote: > > > > since a bad bitstream has potential of frying an FPGA. > > > This argument is invalid. > > > You can fry an FPGA with VDHL and vendor synthesis software. > > This has been demonstrated at the FPL conference a decade ago. > > > I guess the truth is closer to this argument: documenting the > > bitstream format > > is a lot of work and is likely to create only very few additional > > revenue > > from customer that are rather support intensive so it simply isn't > > worthwhile for > > the vendors. > > > I believe that documenting LUT content locations in the bitstream > > would be a good > > compromise. It is relatively easy to document and use and not much can > > go wrong > > and it has a decent amount of applications where it is useful. > > OTOH: The introduction of SRL16 made it easy to support LUT-reloading > > explicitely in the HDL. > > > Kolja > > You can fry an FPGA with VDHL and vendor synthesis software. > > This has been demonstrated at the FPL conference a decade ago. > > I am quite surprised about this. Can you provide any additional > material on how this was achieved? > > There aren't any scenarios, other than internal tri-state contention, > that I can come up with to make this happen with a proven tool chain. > > Ed McGettigan > -- > Xilinx Inc. Since when are tool chains "proven"??? I thought, like nearly all software, they were tested to verify correctness which means they aren't correct at all. RickArticle: 151224
On Mar 14, 11:59=A0am, geobsd <geobsd...@gmail.com> wrote: > > i wanted to use chunks of bit-stream assembled in my model conformance > to process in place of the cpu Uhhh... you can do that. It's called partial reconfiguration. You use Xilinx tools to design a framework which defines the I/O of your design along with any parts that won't be changing. Then you design the pieces that plug into the framework. At any time you can load in any of the pluggable pieces. I was going to use this once, a long time ago, with the Spartan family. But I don't think this ever materialized for the Spartans. But you can do this with the Virtex parts. The partial bitstreams are stored in a file or ROM and a controlling CPU sends them to the FPGA. I think you can even build the CPU into the static part of the FPGA design and it can reload the partial bitstreams itself! Rick
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