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
That's what they like to say. It sounds nice. But software engineers still can't program parallel processor arrays well, let alone FPGAs. These tools can all make a functional FPGA, but if it uses too many gates and has too many levels of logic, you're better off using software.Article: 159076
On 7/26/2016 1:30 PM, Kevin Neilson wrote: > They did claim that software engineers with no hardware experience could be designing FPGAs after a very short training period. Which might have been true. But there's a difference between doing FPGAs and doing them well. I suppose the proof of the pudding is in the eating. Who is using this tool for production in this way? -- Rick CArticle: 159077
On 26/07/16 18:43, Kevin Neilson wrote: > That's what they like to say. It sounds nice. But software engineers still can't program parallel processor arrays well, let alone FPGAs. > > These tools can all make a functional FPGA, but if it uses too many gates and has too many levels of logic, you're better off using software. Be aware that the "high frequency trading" mob put trading algorithms (i.e if X then buy shares Y) into FPGAs to shave off the odd millisecond latency. Obviously development turnaround time for the algorithms is very important. That's a good use-case for software->gates. They've also laid their own $600m trans-Atlantic fibre optic cable to avoid contention and latency, and have bought up all the microwave transmission towers between Chicago and New York because the speed of light in fibres is noticeably slower than that in air.Article: 159078
On 07/25/2016 08:03 PM, adityaishwar1994@gmail.com wrote: > Getting following error at make step: > > adityapappu@adityapappu-NV55C:/opt/Xilinx/usb-driver$ make cc -Wall > -fPIC -DUSB_DRIVER_VERSION="\"2016-07-23 20:34:57\"" usb-driver.c > xpcu.c parport.c config.c jtagmon.c -o libusb-driver.so -ldl -lusb > -lpthread -shared parport.c: In function ‘parport_transfer’: > parport.c:21:23: warning: variable ‘last_pp_write’ set but not used > [-Wunused-but-set-variable] static unsigned char last_pp_write = 0; > ^ /usr/bin/ld: cannot open output file libusb-driver.so: Permission > denied collect2: error: ld returned 1 exit status Makefile:28: recipe > for target 'libusb-driver.so' failed make: *** [libusb-driver.so] > Error 1 adityapappu@adityapappu-NV55C:/opt/Xilinx/usb-driver$ > The first one is a warning and may be harmless, the second one says it can not open libusb-driver.so: Permission denied. check the permissions. Perhaps you had run the build before as root. and now it can not overwrite the file, but that is just a guess...Article: 159079
In article <5792e5fa$0$2798$c3e8da3$76491128@news.astraweb.com>, Allan Herriman <allanherriman@hotmail.com> wrote: > >I find it easy to ignore HLS, but I still suffer from it because it >splits the tool vendors' development budget across multiple tools. > > >I got all excited when I first heard about high level synthesis. Then I >discovered that the language was C - hardly high level, and not >particularly well suited to the sorts of things that FPGA coders need to >do. >It's not about making a better language though - it's about allowing non- >FPGA people to do FPGA things, all in the name of market share. "High Level Synthesis" tools, IMHO are poorly named. Most of the current incantations don't move the design abstraction level up. Rather, they force the abstraction LOWER for the software engineering person. My software team could use HLS tools. They'd have a learning curve to lower their current abtraction level. They'd need to start "thinking hardware", and consider the inherent parallelism of hardware. They're quite capable of this. Problem is they DONT WANT to. They'd prefer to be moving their software coding to a higher level of abstraction (through advances is SW languages and techniques). Then leave all these "fiddly hardware details" to the hardware designers. For the hardware designers, C (or C++) is a very poor basis for a hardware description language. So HLS continues its small market penetration of "unique" designs only... Regards, MarkArticle: 159080
I think Celoxica is defunct.Article: 159081
Mark Curry <gtwrek@sonic.net> wrote: > They're quite capable of this. Problem is they DONT WANT to. They'd prefer > to be moving their software coding to a higher level of abstraction (through > advances is SW languages and techniques). Then leave all these > "fiddly hardware details" to the hardware designers. Indeed. It puzzles me why hardware designers would think that a pile of nested for loops consist of a high level abstraction. If we're concentrating on compute to the exclusion of all else (as HLS seems to), the algorithm might be defined in terms of matrix operations, so surely it's that which should be the input to the HLS toolchain? In a matrix multiply, say, the parallelism is inherent and it is friendly to the programmer: they want to compute matA*matB and all the other details can be left to the tool to figure out. At the very least it leaves plenty more scope for the tool to improve, rather than trying to unpick C loops that represent matA*matB. Matlab isn't a great language for many reasons, but it does make it possible to write code with implicit parallelism pretty easily, without even thinking about it. That would be heading towards my definition of 'high level'. (I'm not familiar with Simulink-to-gates flows, because I'm not a great fan of schematics. Perhaps the tools are better in this space) TheoArticle: 159082
On 7/26/2016 8:11 PM, Kevin Neilson wrote: > I think Celoxica is defunct. So there it is! -- Rick CArticle: 159083
On Wednesday, July 27, 2016 at 11:41:11 AM UTC-3, rickman wrote: > On 7/26/2016 8:11 PM, Kevin Neilson wrote: > > I think Celoxica is defunct. > > So there it is! Celoxica was a very successful company that was bought out by a much larger competitor and immediately shut down. This left many customers who loved the product without any good options. And this is why I refuse to use non open source tools no matter what advantages they claim to have. You can't know if they will still be available tomorrow. The exception (for now) is the vendor tools for generating the FPGA bitfiles. -- JecelArticle: 159084
On 7/27/2016 1:33 PM, Jecel wrote: > On Wednesday, July 27, 2016 at 11:41:11 AM UTC-3, rickman wrote: >> On 7/26/2016 8:11 PM, Kevin Neilson wrote: >>> I think Celoxica is defunct. >> >> So there it is! > > Celoxica was a very successful company that was bought out by > a much larger competitor and immediately shut down. This left > many customers who loved the product without any good options. > > And this is why I refuse to use non open source tools no matter > what advantages they claim to have. You can't know if they will > still be available tomorrow. The exception (for now) is the > vendor tools for generating the FPGA bitfiles. At least with open source tools you can't be disappointed by a total lack of support. My installation of Lattice Diamond errors out when I perform synthesis and I can't get any help from the vendor support... at all! -- Rick CArticle: 159085
Even with your example of a matrix multiplication, there is still a lot to = figure out. For one thing, you usually have to fold the multiplication bec= ause you don't have the resources to do the whole thing in parallel. The M= atlab->gates tool that I used once is long gone. I just spent several days implementing a design that I modeled in two lines= of Matlab code. For a tool to have converted those two lines into a good = hardware implementation would've been difficult.Article: 159086
The high-level design tools I've used weren't very abstracted. To make something work well, I had to keep moving to lower levels of abstraction. In tool that was supposed to be high-level I found myself instantiating DSP48s. Not very abstract.Article: 159087
Here's another example that shows just how far removed we are from high-level synthesis. I need to multiply a 10-bit number by 956. I could use a DSP48, but it's overkill, and to meet timing I'd probably have to pipeline it fully and have 3 cycles of latency. So I write this code and force Vivado not to use DSP48s: reg [9:0] x; // multiplicand reg [19:0] p; // product always@(posedge clk) p <= x*956; This has 58 LUTs, 3 separate columns of carry chains, and fails timing at my clock speed. I'd guess that the synthesizer fully optimizes a simple constant multiplier, but just for fun I go down a level of abstraction, looking at the binary representation of 956, and making a CSD (canonical signed digit) version: reg [9:0] x; // multiplicand reg [19:0] p; // product always@(posedge clk) p <= (x<<10) - (x<<6) - (x<<2); // same as x*956 Results: 19 LUTs, meets timing with 850ps slack. There is only 1 carry chain (ternary add?). So what I am saying is that I can't even use the '*' sign. I have to go down a level of abstraction in order to make a multiplier that will meet timing. If I can't use the multiply sign, why would I believe I could use C code?Article: 159088
Vivado is supposed to be really fast, but I've noticed it parses really slo= wly. To test this I timed it. I have a design with about 20 lines of code= . It uses an undeclared reg. If I try to compile with with Modelsim from = the command line, I get an error immediately. I mean, I can't even time it= because the error message appears while my pinky is still on the carriage = return. When I try to synthesize with Vivado, it takes over 20 seconds jus= t to tell me I have an undeclared reg. That seems like a really long time. Also, it takes over 3 minutes to P&R this design, which comprises a constan= t mult with 50 LUTs. Seems pretty slow.Article: 159089
Kevin Neilson <kevin.neilson@xilinx.com> wrote: > Even with your example of a matrix multiplication, there is still a lot to > figure out. For one thing, you usually have to fold the multiplication > because you don't have the resources to do the whole thing in parallel. > The Matlab->gates tool that I used once is long gone. > > I just spent several days implementing a design that I modeled in two > lines of Matlab code. For a tool to have converted those two lines into a > good hardware implementation would've been difficult. I agree, you can't expect the tool to just do it - there are many things that need to be tweaked. But those are architectural design choices, which are different from writing Verilog or VHDL. By all means expose the tradeoffs to the designer in a way they understand, just don't make them write HDL. Software folks are familiar with the idea of different data structures having difference performance qualities. But by and large a serial 'program' isn't a helpful way to expose tradeoffs to either the software or hardware engineer. As I said, this ignores the elephant in the room that is communication. Your C code has this illusion that it lives in a flat uniform memory space because it's behind a cache, an MMU, a prefetcher and a standard library, that do a lot of work (in terms of time, area and power) to make it look that way. To get good performance, you need both a way to write the compute and a way to move the data around to the right place at the right time. 'HLS' tools are usually poor at handling that: I don't know a HLS 'C to gates' tool that it would make sense to write a cache in, for example. TheoArticle: 159090
rickman wrote:
>
> When I attempt to synthesize through the Diamond GUI
> I get "error code 3".
>
1) Have you tried switching synthesis to LSE then back again?
2) Do you get the same error message if you run
synthesis manually from within the Synplify GUI?
e.g.:
- open project in Diamond
- click the big red "S" in the toolbar
(which opens Synplify with the project sources)
- hit "RUN" in Synplify
- exit Synplify
- back in Diamond, Design->Refresh Design to update status
- run MAP and PAR as usual
-Brian
Article: 159091
I realized that in my application, x probably only needs to be 6 bits wide.=
So I synthesized that, and got something with carry chains in it. Wait a=
minute... if each LUT is a 64-bit lookup table, wouldn't you synthesize a =
constant multiplication by a 6-bit multiplicand as a lookup, with 1 LUT per=
output bit and 1 level of logic? Yes, you would. No carry chains. But i=
n order to do that, I had to write the logic like this:
reg [5:0] x;
always@(posedge clk)
case(x)
0: p<=3D956*0;
1: p<=3D 956*1;
...
63: p<=3D956*63;
endcase
Yes, that's how I had to write it. High-level synthesis!
Article: 159092On Wednesday, July 27, 2016 at 7:21:26 PM UTC-4, Kevin Neilson wrote: > Vivado is supposed to be really fast, but I've noticed it parses really s= lowly. To test this I timed it. I have a design with about 20 lines of co= de. It uses an undeclared reg. If I try to compile with with Modelsim fro= m the command line, I get an error immediately. I mean, I can't even time = it because the error message appears while my pinky is still on the carriag= e return. When I try to synthesize with Vivado, it takes over 20 seconds j= ust to tell me I have an undeclared reg. That seems like a really long tim= e. >=20 > Also, it takes over 3 minutes to P&R this design, which comprises a const= ant mult with 50 LUTs. Seems pretty slow. If Brand X isn't up to snuff, maybe switch to Brand I, formerly A. Kevin JenningsArticle: 159093
Interestingly, the following loop also implements the multiply as a lookup =
table with 1 LUT per output bit without having to write out the case statem=
ent. =20
reg [5:0] x;
integer ii;
always@(posedge i_clk)
for (ii=3D0; ii<64; ii=3Dii+1)
if (x=3D=3Dii) p <=3D 956*ii;
One thing you have to do in this field is to constantly look at the synthes=
ized design to see if it came out how you'd planned. That is something hig=
h-level users aren't supposed to have to do. Imagine if a Javascript coder=
had to look at the compiled machine code to see if the compiler did what h=
e wanted. I don't think they work on that level.
Article: 159094On 7/27/2016 8:49 PM, Brian Davis wrote: > rickman wrote: >> >> When I attempt to synthesize through the Diamond GUI >> I get "error code 3". >> > > 1) Have you tried switching synthesis to LSE then back again? > > 2) Do you get the same error message if you run > synthesis manually from within the Synplify GUI? > e.g.: > - open project in Diamond > - click the big red "S" in the toolbar > (which opens Synplify with the project sources) > - hit "RUN" in Synplify > - exit Synplify > - back in Diamond, Design->Refresh Design to update status > - run MAP and PAR as usual Thanks for the suggestions. I had already switched the tool too LSE and back because that's the only way to get the Diamond refresh tool to use VHDL-2008. But I did it again and this time tried running the LSE synthesis which worked. But I can't use LSE for the chip I am working with, an old XP device. I have already tried running Synplify manually and it does not start bringing up an error report that doesn't say anything about the error, but tells me to call Synopsis support. I recall that a license issue with Synplify returns an "error 2". This returns an error 3 when from from within Diamond. Why is Lattice support being such buttheads? They asked me for a screenshot of the directory dialog for the installation directory which I provided. Then no reply for a week and a half. I've made two more replies with additional information and still nothing. -- Rick CArticle: 159095
On 7/27/2016 11:13 PM, rickman wrote: > On 7/27/2016 8:49 PM, Brian Davis wrote: >> rickman wrote: >>> >>> When I attempt to synthesize through the Diamond GUI >>> I get "error code 3". >>> >> >> 1) Have you tried switching synthesis to LSE then back again? >> >> 2) Do you get the same error message if you run >> synthesis manually from within the Synplify GUI? >> e.g.: >> - open project in Diamond >> - click the big red "S" in the toolbar >> (which opens Synplify with the project sources) >> - hit "RUN" in Synplify >> - exit Synplify >> - back in Diamond, Design->Refresh Design to update status >> - run MAP and PAR as usual > > Thanks for the suggestions. I had already switched the tool too LSE and > back because that's the only way to get the Diamond refresh tool to use > VHDL-2008. But I did it again and this time tried running the LSE > synthesis which worked. But I can't use LSE for the chip I am working > with, an old XP device. > > I have already tried running Synplify manually and it does not start > bringing up an error report that doesn't say anything about the error, > but tells me to call Synopsis support. > > I recall that a license issue with Synplify returns an "error 2". This > returns an error 3 when from from within Diamond. > > Why is Lattice support being such buttheads? They asked me for a > screenshot of the directory dialog for the installation directory which > I provided. Then no reply for a week and a half. I've made two more > replies with additional information and still nothing. I noticed there was an update so I installed it, no change. I just realized that when I was having trouble with the tool recognizing I was using VHDL-2008, they told me to change the VHDL setting in LSE. I didn't have an option to change any LSE settings. Support wasn't on the ball enough to figure out that you can't use LSE with the old XP parts. Wow... -- Rick CArticle: 159096
Hi all, I have a design that uses Altera Ethernet MAC and I would like to connect it to NIOS without DMA. Any suggestions? Thanks, -- JakabArticle: 159097
Jakab Tanko <jakab.tanko@gmail.com> wrote: > Hi all, > > I have a design that uses Altera Ethernet MAC and > I would like to connect it to NIOS without DMA. > Any suggestions? The MAC (at least the 10G MAC which I've worked with) has Avalon stream pipes in and out for packet data. So you just need something to generate a stream of 64 bit words. The Altera supplied stream-to-memory-mapped components only go as wide as 32 bits. So I wrote a very simple FIFO to stream converter, with 64 bit Avalon ST and 32 bit Avalon MM ports. Write words into a pair of 32 bit FIFO registers, 64 bit words come out on the stream. Another register handles start-of-packet/end-of-packet bits. You probably don't want my code (it's in Bluespec), but it shouldn't take long to write something similar. Alternatively you could use the Altera 32 bit components and make something to double up two words on a 32 bit stream to be a single 64 bit stream word. TheoArticle: 159098
Kevin Neilson wrote: > Vivado is supposed to be really fast, but I've noticed it parses really slowly. To test this I timed it. I have a design with about 20 lines of code.. It uses an undeclared reg. If I try to compile with with Modelsim from the command line, I get an error immediately. I mean, I can't even time it because the error message appears while my pinky is still on the carriage return. When I try to synthesize with Vivado, it takes over 20 seconds just to tell me I have an undeclared reg. That seems like a really long time. > > Also, it takes over 3 minutes to P&R this design, which comprises a constant mult with 50 LUTs. Seems pretty slow. I've just started using Vivado, which was supposed to be a ground-up totally new software with no inheritance from ISE. However I have already noticed that it has some of the same quirks that ISE does. One thing I noticed in ISE, and it may be related to the time you take to find an error, is that when you ask to check syntax on one module it actually parses the entire design hierarchy - even if the module you wanted checked is only in the project but not a part of the design hierarchy. Other quirks include pointing to a different net when reporting a multi-driven net. Generally when Vivado reports a multi-driven net there is one somewhere in the design, just not the net it is reporting. Good luck finding the actual net. I used to have a similar issue in ISE where it would report GND as multi-driven. What was clearly a totally new design is the user interface. Even when Vivado has the exact same function as ISE you need to know the new name to find it. For example, "IP Integrator" is clearly Core Generator just repackaged for Vivado. By the way, when you say Vivado took 20 seconds to find the error, was that running simulation or synthesis? -- GaborArticle: 159099
That is running "synthesis". It doesn't actually get to synthesis, since there is an elaboration(?) error. I've actually never used the Vivado simulator. I could never even get Isim to parse my code, so I haven't tried a Xilinx simulator in years.
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