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
David Brown <david.brown@hesbynett.no> wrote: > What sort of sizes are you talking about for these files? The total size of files touched is of the order of gigabytes. > If you have enough ram, so that they are in your disk caches, then disk > latency will be pretty much irrelevant. When the app writes the files, > they go into cache - the actual write to disk takes place asynchronously > unless the app specifically waits for it - the delay before hitting the > disk surface does not matter. When the app reads the files, they are > already in cache and the data is returned immediately. (This is on > Linux - Windows tends to wait for files to be written out, then might > clear them from cache so that they must be re-read later.) That doesn't help if you're touching the file for the first time. In the case of building collections of IP you scan the library files (lots of small verilog files) which means lots of small reads of disparate files. Bear in mind that FPGA builds are long enough that the files may go into the cache, but they aren't there when your build completes after an hour and you start a new build. On 16GB-class desktops/laptops there's enough going on that the cache probably doesn't stick around long enough. TheoArticle: 159301
On 27/09/16 08:18, Theo Markettos wrote: > David Brown <david.brown@hesbynett.no> wrote: >> What sort of sizes are you talking about for these files? > > The total size of files touched is of the order of gigabytes. > >> If you have enough ram, so that they are in your disk caches, then disk >> latency will be pretty much irrelevant. When the app writes the files, >> they go into cache - the actual write to disk takes place asynchronously >> unless the app specifically waits for it - the delay before hitting the >> disk surface does not matter. When the app reads the files, they are >> already in cache and the data is returned immediately. (This is on >> Linux - Windows tends to wait for files to be written out, then might >> clear them from cache so that they must be re-read later.) > > That doesn't help if you're touching the file for the first time. In the > case of building collections of IP you scan the library files (lots of small > verilog files) which means lots of small reads of disparate files. That is true, for the first time you read them (after booting, or waking from sleep). Thereafter the files are in the cache. > > Bear in mind that FPGA builds are long enough that the files may go into the > cache, but they aren't there when your build completes after an hour and you > start a new build. On 16GB-class desktops/laptops there's enough going on > that the cache probably doesn't stick around long enough. The key here is to have enough memory so that this does not happen. That is a challenge on a laptop, because you seldom get lots of memory - but on a desktop/workstation for FPGA design, 24 GB or 32 GB is not going to be unreasonable (32 GB is a similar price to a reasonable SSD). > > Theo >Article: 159302
I am implementing the gamma correction LUT as in https://ptpb.pw/ZwYS if I want to share a single combinatorial lookup table with multiple input, it is not possible, right ? because in this case, the lookup table would just assign to one output reg say all r, g and b channels want to use the same combinatorial lookup table, how would I do it ? Someone suggested the following, could anyone advice ? mux -> lut -> demux But my friend told me the following instead: A 256-sized table can be done in one slice, containing 4-luts--for every output bit. It will consume all 4 luts of the slice. So ... we're talking about 8 slices, or 32-luts, per color. 96 LUTs is reasonable. Now, if you wished to somehow re-use those 96 LUTs to get your logic down to a smaller size, be prepared for the fact that it will cost logic to make any logic change--perhaps as much as the 96 LUTs that you would originally need.Article: 159303
kristoff <kristoff@skypro.be> wrote: > Well, what got me thinking is the fact that my employer now has a > project with HP which includes an additional reduction on the price, but > -in the other hand- really limits my choice. > > As I work about 120 km from where I live for 3 days in a week, I am more > interested in a laptop with a limited screen-size as I do need to carry > the thing on the train and in my backpack every day). > > I do have a large external screen at home. Do you work on the train? Or is the requirement simply for portability? One of our remote workers uses a Skull Canyon NUC. This has an i7 with EDRAM so is reasonably quick a Quartus compiles. It's about 5% off the best out there (the i7-5775c) - the EDRAM is shared with the GPU and there's no way to plug in an external GPU. It's a 'portable desktop' rather than a laptop - he has a second power supply, so just needs to carry the NUC around and plug it into power, USB and monitor in each place. Intel have put a lot of effort into the cooling solution for such a small package - it's not a 95W desktop, but performance is pretty close. One possible advantage of the NUC is you can point at it and say 'HP don't sell anything like that' which might work around purchasing requirements. Otherwise I'd suggest looking at graphics workstation laptops (eg Xeon). I'm not familiar with what HP have, but likely small and light they aren't. TheoArticle: 159304
An interesting video:
C to FPGA Compilation and Domain-Specific Computing
https://www.youtube.com/watch? v=TNF8EhKDM1c
A tool stack taking C and C variants to FPGA, along with some
findings on different approaches, and at different speed
targets in optimization. Very little concern over power budgets
in their current implementation, but consideration in the
future by additional optimization and / or customization.
Best regards,
Rick C. Hodgin
Article: 159305On Tuesday, September 27, 2016 at 7:31:56 PM UTC-6, Marvin L wrote: > I am implementing the gamma correction LUT as in https://ptpb.pw/ZwYS >=20 > if I want to share a single combinatorial lookup table with multiple inpu= t, it is not possible, right ? >=20 > because in this case, the lookup table would just assign to one output re= g >=20 > say all r, g and b channels want to use the same combinatorial lookup tab= le, how would I do it ? >=20 You can share a blockRAM-based lookup table between two users. A LUT-ram-b= ased lookup can't be shared unless you timeslice it. Yes, you can do a 256= ->1 lookup in one Virtex-7 slice (using 4 LUTs, 2 F7, and 1 F8 mux). I looked at your function and it doesn't look like you can use a lookup tab= le. There is a 3x3 matrix multiplication so the output is a function of R,= G, and B, so if you wanted to do a lookup the table would have to be 3-dim= ensional and have 256^3 elements. I think you actually have to implement t= he logic in this case. Because the R,G,B inputs are only 8 bits each, you = can still implement the multiplications in 256-deep lookup tables, but you'= d still need to sum the results together to get the result of the matrix mu= lt.Article: 159306
>=20 > C to FPGA Compilation and Domain-Specific Computing > https://www.youtube.com/watch? v=3DTNF8EhKDM1c >=20 > A tool stack taking C and C variants to FPGA,=20 In the video he notes that he had to rewrite the inner loops at a low level= to optimize them for hardware synthesis. This is a characteristic of all = of these tools: you rewrite it in very low-level code to get it to work we= ll in hardware. Guess what? You are now doing hardware engineering. You'= ve gained absolutely nothing.Article: 159307
Kevin Neilson wrote: > In the video he notes that he had to rewrite the inner loops at > a low level to optimize them for hardware synthesis. This is a > characteristic of all of these tools: you rewrite it in very low-level > code to get it to work well in hardware. What was the mm:ss? I'd like to put his note in context. Best regards, Rick C. HodginArticle: 159308
Rick C. Hodgin wrote: > Kevin Neilson wrote: > > In the video he notes that he had to rewrite the inner loops at > > a low level to optimize them for hardware synthesis. This is a > > characteristic of all of these tools: you rewrite it in very low-level > > code to get it to work well in hardware. > > What was the mm:ss? I'd like to put his note in context. I watched it again. The toolset is able to take unaltered C code, or System C code, and process it through. An MPEG-4 example showed a target achieved of 30 fps on unaltered code. The considerations regarding optimization allow for various targets. For some high speed throughput goals the target is not achievable through the toolset due to hardware use limitations on logic units or work per clock. In those cases rewriting C algorithms to lower- level ops can then coax the toolset to produce a solution for your RTL needs. It's an enabler for higher speed goals, but, it is not required in general to produce a workable model for FPGA or ASIC. Best regards, Rick C. HodginArticle: 159309
At about 35 minutes or so he also talks about a startup company that licensed the toolset for commercial use. The presenter said they have expanded the toolset into C++. They are former students of his. Best regards, Rick C. HodginArticle: 159310
On Mon, 26 Sep 2016 21:29:21 +0200 kristoff <kristoff@skypro.be> wrote: > On 26-09-16 21:12, Jan Coombs wrote: > > Probably only you will know whether you prefer to write every > > thing in triplicate, or fall between the stepping stones. > > Well, my first interest is to understand the code written by > others in the many open-source projects out there. I've done a lot of that, good for getting comfortable with RTL and other novel aspects of hardware design. You did shake my belief expressed in my intuitive comment above, so I checked a project, and attached a summary below; the VHDL exported is almost double the size of the verilog. > > Alternatively, if you model in MyHDL [1] it can export > > either, or even both. > > Isn't it best first to learn (or at least to understand) the > two "main" languages and then move on to the alternatives? Its not like English vs Chinese! Whether you prefer the terse or verbose, the underlying RTL is what you need to grok. My preference is the less extreme choice, MyHDL. MyHDL is a fast[2] free modelling tool, with substantial support of Python libraries for design and test, and exports to waveform viewer. Downside: you need good testing to prove design source is valid and interpreted correctly[3]. Upside: you should be doing this anyway! As for writing Verilog/MyHDL/VHDL, use code templates, your own or from net or tool manuals. Enjoy the trip, this low-level stuff still fascinates me. Jan Coombs -- [1] myhdl.org [2] http://old.myhdl.org/doku.php/performance [3] http://docs.myhdl.org/en/stable/manual/unittest.html # Sample_DesStruct.utxt 2014-11-08 jc Check imports, update to ... Project source code tree: kB LoC Idx -- --- --- 7.0 170 1 1.9 50 1.1 5.1 116 1.2 5.2 139 1.3 6.9 180 1.3.1 10.0 265 1.4 4.1 60 1.4.1 2.2 90 1.4.2 4.3 102 1.5 5.3 156 1.5.1 1.6 60 1.4.1.1 1.5 60 1.5.1.2 17.0 436 1.5.2 2.3 90 1.5.2.1 14.1 333 1.5.3 6.7 161 1.5.3.1 9.7 246 1.5.4 ---- ---- 104.9 2794 Full Project Exports for Synthesis: kB LoC -- --- 94.1 2714 MyProj.v 173.9 2813 MyProj.vhd + 3k4B library Notes: Exported files contain block header comments only, the comment sizes are identical: kB LoC -- --- 6.0 164 MyProj_NoCode.v 6.0 164 MyProj_NoCode.vhd Source file code style is more compact than exports, and uses 2 space tabs, exports use 4 space tabs. Hardware fabric after synthesis: 609 LUT4+FFs 3 RAMsArticle: 159311
> Some have a quite strong=20 > opinion that Verilog is much more productive and useful. I won't argue= =20 > about it until I learn Verilog better. Simply speaking: Verilog compiles every piece of code, VHDL compiles none... VHDL does very strong type checking and also has a verbose syntax which is = quite cumbersome, but at least, when the compiler does not complain, chance= s are high that the code does what the designer intended. Two hints: - Make use of some VHDL-2008 features (like process(all)) - Understand that you do not need component declarations, you can use inst: entity work.foobar(rtl) port map (...) without component statement. Verilog will save you some time writing code but can result in extremely ha= rd to find errors that turn out to be simply typos. At least a good editor = is a must and I would suggest to read this: http://www.lcdm-eng.com/papers/= snug06_Verilog%20Gotchas%20Part1.pdf Can't comment on MyHDL and SystemVerilog... Regards, Thomas www.entner-electronics.com - Home of EEBlaster and JPEG-CodecArticle: 159312
On Fri, 2 Sep 2016 13:53:25 -0700 (PDT) thomas.entner99@gmail.com wrote: > In my youth I tried to build a GAL programmer, but I never got > it to work with the samples I had. Youth, thats the bit I missed out on, I was a mature student then I did the EPLD work. > Later I found out that there appeared to be quite different > programming algorithms for different parts with the same name, > so be aware... I did have the (NDA) programming documents from LatticeSemi and Intel for these parts, and seem to remember that the Lattice programming algorithms were not complete in the regular chip documentation. While moving Lattice tools around I noticed that here: /home/.../Diamond/IspVMsystem/isptools/ispvmsystem/Database/ee9/22v10a/ are these files: ispgal22v10avp28_spi_loader.jed ispgal22v10avq32_spi_loader.jed ispVM_005b.xdf Perhaps some of the tools do still exist? > Thomas Jan Coombs --Article: 159313
On 10/2/2016 10:09 AM, thomas.entner99@gmail.com wrote: >> Some have a quite strong opinion that Verilog is much more >> productive and useful. I won't argue about it until I learn >> Verilog better. > > Simply speaking: Verilog compiles every piece of code, VHDL compiles > none... > > VHDL does very strong type checking and also has a verbose syntax > which is quite cumbersome, but at least, when the compiler does not > complain, chances are high that the code does what the designer > intended. Yes, that is the point of strong typing. It should eliminate the class of errors that are due to mistakes in cross type assignments. This is something that you have to understand very thoroughly in order to use Verilog because it won't warn you, it will just do something that may or may not be what you want. This is where I am not sure which is preferable. I can write VHDL code easily in spite of the "verboseness" of the language. I have yet to even find a good book that tells you how to deal with these issues in Verilog. I have asked about a good book to learn these issues from an have been told in the Verilog group that there is none. Until I can learn about this and be certain I am writing good code, I can't really consider using Verilog professionally. > Two hints: - Make use of some VHDL-2008 features (like process(all)) > - Understand that you do not need component declarations, you can > use inst: entity work.foobar(rtl) port map (...) without component > statement. > > Verilog will save you some time writing code but can result in > extremely hard to find errors that turn out to be simply typos. At > least a good editor is a must and I would suggest to read this: > http://www.lcdm-eng.com/papers/snug06_Verilog%20Gotchas%20Part1.pdf Wow. This is a pretty long paper about "gotchas" in Verilog... 63 pages! I'm not sure I want to work with it. -- Rick CArticle: 159314
On 03/10/16 04:05, rickman wrote: > On 10/2/2016 10:09 AM, thomas.entner99@gmail.com wrote: >> Verilog will save you some time writing code but can result in >> extremely hard to find errors that turn out to be simply typos. At >> least a good editor is a must and I would suggest to read this: >> http://www.lcdm-eng.com/papers/snug06_Verilog%20Gotchas%20Part1.pdf > > Wow. This is a pretty long paper about "gotchas" in Verilog... 63 pages! I'm > not sure I want to work with it. How about C/C++? There are many discussions their "characteristics"; I like the wryly amusing FQA http://yosefk.com/c++fqa/ Having first used C in 1981 (gulp), I now feel uncomfortable using it for anything more than a hack. Can you "cast away constness" at the moment? I remember reading endless discussions in the early 90s about whether it should be allowed or forbidden in the standard.Article: 159315
Hi, Not sure if this forum is still alive but I am using Amontec JTAGKey2 and t= he Amontec SVF player to program a Virtex-7 Eval board. The svf player got = to "SVF Playing File:" and then I got an error message: "Error code =3D 524 (Line: 0 Error 524: parser_svf -> File not found.)" What gives? Where do I get this parser_svf file? On Thursday, July 26, 2007 at 4:52:55 PM UTC+8, Amontec, Larry wrote: > Amontec, Larry wrote: > > Amontec, Larry wrote: > >=20 > >> Amontec, Larry wrote: > >> > >>> ON NEXT MONDAY : 17-JUNE-2006 > >>> > >>> Amontec will provide the =E2=80=98how-to=E2=80=99 program via a XILIN= X VIRTEX XC4VLX25 > >>> 7.9Mbits bit stream) at 2.8 seconds using the Amontec JTAGkey ! > >>> > >>> On next Monday, your Amontec JTAG key will be close to the speed of a= =20 > >>> Xilinx Platform Cable USB for programming any FPGA and CPLD vendors= =20 > >>> (Altera Xilinx Lattice Cypress ...) > >>> > >>> Come back next Monday on http://www.amontec.com ! > >>> > >>> Laurent > >> > >> > >> > >> Hi all, > >> > >> You may download the Amontec SVF Player from > >> http://www.amontec.com/jtagkey.shtml > >> > >> Already tested for programming Altera Lattice Xilinx FPGA s CPLD s and= =20 > >> FLASH s. > >> It can be use for programming AVR ATMEGA processors too. > >> But you may use it as custom JTAG Boundary Scan. > >> > >> Infini SCAN LENGTH ! > >> Infini number of TAP (number of Targets) integrating Header and=20 > >> Trailer scans. > >> > >> The amtsvfplayer.exe comes with c project source. Also, you may edit= =20 > >> the source, customize it and re-compile a new SVF Player for your=20 > >> specific needs. > >> > >> amtsvfplayer.exe -h to get help on usage. > >> > >> You may execute SVF Files or SVF Lines. > >> A SVF Line could be a concatenation of SVF commands. > >> > >> You may adapt JTAG Frequency (FREQUENCY) via -frequencyFactor. In this= =20 > >> way you do not need to edit the SVF yourself. When using=20 > >> -frequencyFactor, the RUNTEST x TCK is automaticaly updated ... > >> > >> Linux version ready to be published. > >> > >> HAVE FUN WITH JTAG AND SVF ! > >> ... but you need to have the JTAGkey. > >> > >> Regards, > >> Laurent > >> http://www.amontec.com > >> > >> Ann: via JTAGkey, you have a lot of ARM Debug Solutions too, including= =20 > >> OpenOCD JTAG server, Crossworks, Yagarto ... ! > >=20 > >=20 > > Timing for small devices: > >=20 > > Xilinx Coolrunner XCR3128 ERASE / PROGRAM / VERIFY -> > > JTAG generation from SVF Player > > SVF used : > > http://www.amontec.com/chm_appl_test_led_blink_prog_check.svf > > ... in 601 milliseconds > >=20 > > ScreenShot : > > http://www.amontec.com/jtagkey.shtml > >=20 > > Regards, > > Laurent > We have tested with an big Altera EPC2S 16.9Mbits bitstream (SVF file)=20 > and the Amontec JTAG download it after a 4.4 seconds ! > Laurent > http://www.amontec.comArticle: 159316
On Sunday, October 2, 2016 at 2:40:25 AM UTC+2, Rick C. Hodgin wrote: > At about 35 minutes or so he also talks about a startup company > that licensed the toolset for commercial use. The presenter > said they have expanded the toolset into C++. They are former > students of his. >=20 > Best regards, > Rick C. Hodgin The tool he is talking about is xPilot, which was then licensed to AutoESL = under the name AutoPilot. The AutoESL was later bought by Xilinx which re-b= randed the tool as Vivado HLS. The signs of it previous name still remain i= n the names of the types, e.g. ap_int, ap_fixed.Article: 159317
Jan Marjanovi=C4=8D wrote:
> The tool he is talking about is xPilot, which was then licensed
> to AutoESL under the name AutoPilot. The AutoESL was later
> bought by Xilinx which re-branded the tool as Vivado HLS. The
> signs of it previous name still remain in the names of the types,
> e.g. ap_int, ap_fixed.
Thank you! Linked here:
https://www.xilinx.com/products/design-tools/vivado/integration/esl-des=
ign.html
Best regards,
Rick C. Hodgin
Article: 159318for muxen. during combinatorial optimization. in berkeley-abc. I am using the binary aig format for importing. It knows only about `and' and `inverter' gates. During optimization the safety terms get dropped (the AB in: Ax + B~x + AB) Should I use a different import format? Which one? I'd like to end up with a .pla file or similar in the end. If you think this is offtopic feel free to suggest another ng...Article: 159319
On Wednesday, October 5, 2016 at 9:26:45 PM UTC-4, Johann Klammer wrote: > for muxen. during combinatorial optimization. in berkeley-abc. > I am using the binary aig format for importing. > It knows only about `and' and `inverter' gates. > During optimization the safety terms get dropped > (the AB in: Ax + B~x + AB) > Should I use a different import format? > Which one? > I'd like to end up with a .pla file or > similar in the end. > > If you think this is offtopic feel free > to suggest another ng... I have no idea what tool you are using, but you'll need to look into the tool specific way to preserve signals. Kevin JenningsArticle: 159320
On 10/06/2016 03:41 AM, KJ wrote: > > I have no idea what tool you are using, but you'll need to look into > the tool specific way to preserve signals. > > Kevin Jennings > It's not about a signal, but a (redundant) term getting lost during the simplification (in abc here: <https://bitbucket.org/alanmi/abc>) That is, the term is redundant w.r.t logic, but not in terms of timing(glitches). Searching for `hazard' in the repository (.c files) does not give a match. There are methods in there to find muxen, so maybe sthg can be cobbled together from that. But before doing that I'd rather ask here if I've missed something, or maybe there's something similar wot can do this already.Article: 159321
On 10/05/2016 08:17 PM, Johann Klammer wrote: > On 10/06/2016 03:41 AM, KJ wrote: >> >> I have no idea what tool you are using, but you'll need to look into >> the tool specific way to preserve signals. >> >> Kevin Jennings >> > It's not about a signal, but a (redundant) term getting lost during the > simplification (in abc here: <https://bitbucket.org/alanmi/abc>) > That is, the term is redundant w.r.t logic, but not in terms of timing(glitches). > Searching for `hazard' in the repository (.c files) does not give a match. > There are methods in there to find muxen, so maybe sthg can be cobbled > together from that. > But before doing that I'd rather ask here if I've missed something, or > maybe there's something similar wot can do this already. > Assuming that the safety terms are getting removed at synthesis time, look for a "SET NOTOUCH" directive. I have used it with Xilinx tools in similar situations with Verilog, and it worked. BobHArticle: 159322
On 10/06/2016 05:55 AM, BobH wrote:
>
> Assuming that the safety terms are getting removed at synthesis time,
> look for a "SET NOTOUCH" directive. I have used it with Xilinx tools in similar situations with Verilog, and it worked.
>
> BobH
You can preserve them with abc? (That's where they disappear here.) what commands do you use?
Here's what I used (on a popen()ed abc instance.. C code):
extern void
dump_pla15 (syn_ctx * ctx)
{
FILE *fp = ctx->abcfp;
char *buf = NULL;
asprintf (&buf, "%s/%s", ctx->tmpdir, "atf15.pla");
fprintf (fp, "read_aiger %s/nopt.aig\n", ctx->tmpdir);
fprintf (fp, "drw\n");
fprintf (fp, "refactor\n");
fprintf (fp, "collapse\n");
fprintf (fp, "write_pla %s\n", buf);
fflush (fp);
free (buf);
buf = NULL;
}
Article: 159323Guys I have two FPGAs with 4 MGTs connected between them using Aurora. The firmware guy has insisted (and I've taken a quick look myself) that we cannot define the link order. This means that I have to layout the PCB with the MGTs crossing over each other. Really? I can't easily ask Xilinx directly because it is the firmware guys responsibility hence my post here. Does anyone here know whether this is definitely the case or not? Sorry to use google to post this. I am certain that making a technical request to an admin dept run by HP in India to allow me proper usenet access will not succeed. ColinArticle: 159324
On 10/5/2016 11:17 PM, Johann Klammer wrote: > On 10/06/2016 03:41 AM, KJ wrote: >> >> I have no idea what tool you are using, but you'll need to look into >> the tool specific way to preserve signals. >> >> Kevin Jennings >> > It's not about a signal, but a (redundant) term getting lost during the > simplification (in abc here: <https://bitbucket.org/alanmi/abc>) > That is, the term is redundant w.r.t logic, but not in terms of timing(glitches). > Searching for `hazard' in the repository (.c files) does not give a match. > There are methods in there to find muxen, so maybe sthg can be cobbled > together from that. > But before doing that I'd rather ask here if I've missed something, or > maybe there's something similar wot can do this already. I may be way off base here, but I think this is something that is not applicable to FPGAs. FPGAs use a LUT for logic. This is exactly equivalent to the Karnaugh map table that is filled in with 1s and 0s. Notice I didn't say anything about grouping terms for simplification. That is because none of that is needed when you have such a table. Since there is no grouping of terms, preserving term groups is meaningless. Are you intending for the logic to generate multiple LUTs with these terms separate and another LUT to OR them together? I can't say for sure about every FPGA family, but Xilinx has indicated they design the muxes in their LUTs to be hazard proof for the problem you are trying to prevent. They do this by the use of transmission gates rather than logic. As the transmission gates turn off and on, the capacitance of the output line keeps the present value until the next transmission gate turns on driving the output to the new value. If the old and new values are the same, no glitch guaranteed. Does this address your concerns? -- Rick C
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