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
Good evening folks, I m studying the different ways adopted by altera xilinx and lattice to secure bitstream. As a priori knowledge , XILINX (virtex5) method is the most efficient but i still have some questions about this. => When the decryptor start to run ? after receiving the first configurable data (written to FDRI register) ? or after verifying the ECC of the first frame ? => if an encrypted bitstream is loaded to FPGA with a wrong key, the decryptor starts to run anyway ? => there is no other solution to replace the backup battery ? Thank you .Article: 137101
Jan wrote: > Dear All, > > I'm trying to make a peripheral in XPS. I've used the "Create or Import > Peripheral" wizard to create the peripheral. > I can also get the thing to compile and I also successfully added the IP > to my MicroBlaze design. > > However, now I want to add more advanced stuff to the peripheral and > therefor need to add userports. I just don't know how to do it. I have > added some ports in the IP Entity and also added them in the MPD file. > > But still nothing shows in the "System Assembly View" when I add the IP. > Only the ports that was already there. > You might also want to "Project -> Rescan User Repositories" To force EDK to update the information coming from the changed .mpd. Regards, LorenzArticle: 137102
Hi, I know DFF is: module DFF(d,clk,q) ; input d, clk ; output reg q ; always @(posedge clk) q<= d ; endmodule Now I need to implement ASYNCHRONOUS RESET flip flop using DFF ONLY, may be some extract logic. HOW CAN I DO THAT ? The implemented circuit MUST WORK AS FOLLOWS: module DFFR(d,clk,r, q) ; input d, clk,r ; output reg q ; always @(posedge clk or posedge r) if (r) q <= 0 ; else q<= d ; endmodule Please give the code or diagram. I am curious about this. SantArticle: 137103
Hi, I have to map some scientific application algorithms on FPGA using a High Level Language (HLL) and not VHDL. I am lost regarding the choice of the HLL language to use which not only allows efficient mapping but also the user to alter and enhance the compiler and the mapping in general, preferably open source compiler! I got conflicting feedbacks about Mitrion-C in particular which i was using to use. some suggested Handel-C other Mitrion-C, etc...i could not find a rigourous comparative studies. could you share your experience with us and/or any advice Cheers,Article: 137104
santhosh_h_98@yahoo.com wrote: > Hi, > > I know DFF is: > > module DFF(d,clk,q) ; > input d, clk ; > output reg q ; > > always @(posedge clk) > q<= d ; > endmodule > > Now I need to implement ASYNCHRONOUS RESET flip flop > using DFF ONLY, may be some extract logic. HOW CAN I DO THAT ? > > The implemented circuit MUST WORK AS FOLLOWS: > > module DFFR(d,clk,r, q) ; > input d, clk,r ; > output reg q ; > > always @(posedge clk or posedge r) > if (r) q <= 0 ; > else q<= d ; > endmodule > > Please give the code or diagram. I am curious about this. > Well actually that'll cost logic in the clock path. You'll most likely have to create an own clock clk_dffr which is clk or rst; and you'll need d_dffr which will be d and not rst. That should solve the task (though I'm not happy about that solution, but no better one came to my mind). > Sant Regards, LorenzArticle: 137105
jeremywwebb@gmail.com wrote: > On Dec 22, 2:07 pm, Jan <1...@2.3> wrote: >> However, now I want to add more advanced stuff to the peripheral and >> therefor need to add userports. I just don't know how to do it. I have >> added some ports in the IP Entity and also added them in the MPD file. >> >> But still nothing shows in the "System Assembly View" when I add the IP. >> Only the ports that was already there. > Did you add the PORT(s) to your IP instance in the MHS file? If you > don't add the PORT(s) to the IP instance in the MHS file, then they > won't show up in the "Ports" tab in XPS. Another way to get the ports > to show up is to re-import the IP in XPS. This will only work if > you've added the ports in the top-level IP HDL file and the MPD file. Ok, after trying to add the port in the MHS file it showed up in the assembly view. Now a new problem appeared. I don't know how to map the new port to a physical port. Where can I add new locations that then can be selected in the assembly view? Regards JanArticle: 137106
On Dec 23, 4:46 am, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote: > >Actually, this is a potential paid app, but is not likely to be the > >first. The first is going to be part of a test fixture for the > >modules which are currently being built for the time code signal app. > >There may be some character processing, but not much. However, I > >don't want to hamstring later apps and I prefer to make the processor > >as flexible as practical now. > > You don't have to make it "the" processor. You can tweak the > instruction set for each application. That's probably not > worth the effort, but it might be critical for some application. > > (I'm assuming you are writing small chunks of code rather than > large things like operating systems or compilers.) > > A couple of ideas to add to your bag of tricks... > > You can get constants from a ROM. So a load-immediate of a big > number (16 bits) doesn't take 3 bytes of instruction. It's one > byte of instruction and a couple of bytes in another ROM. > That assumes you have enough bits in the instruction to do > a table lookup. Actually, it only takes two 9 bit instructions to provide a 16 bit literal on the return stack. It takes another 9 bit instruction to move it to the data stack. Your approach uses two bytes for the data and a byte for the instruction. How is that a savings? If you consider the potential wasted space from breaking the program space into a lookup table and code space, I don't see how this would be at all useful. In Koopman's code analysis, the instruction at the top of each list was the CALL (which needs an address constant). LIT was number 2 on the static list and 5 on the dynamic list. VARIABLE and 0BRANCH were high up in the list too. So the instruction I optimized the most was RLIT which uses 1 bit to specify the instruction and the remaining bits as data. The RLIT instruction sets a flag so that the first RLIT pushes its data on the stack. Subsequent RLIT instructions shift their data into the stack to build longer constants. Any other instruction clears the literal flag. I don't think you can get much better than this for constant data. > In the old days, instruction sets like this were implemented > with microcode. One hack that gives you a lot of flexibility > is to do a dispatch on the op-code. That lets you use > fractional-bits for various fields. Say you have 3 > opcodes that all want 10 different values for immediate/constants. > You don't have to round up to 16 values, That would take > 4x16 slots. Instead, you can do a table lookup (ROM again) > on the op-code and pack them into 30 slots. That may cost > you a pipeline cycle. > > ROMs are handy for opcode decoding. Take your 8 or 9 bits > (or part of them) and feed that into a wide ROM that gives > you all the decoded control signals you need. This is sliding > toward the microcode way of thinking. That sounds nice, but a ROM in an FPGA uses the sync RAM blocks. They require a clock edge to produce an output and most of the delay is on the output side. This is pathologically slow for use as microcode. Also block RAMs can be a precious resource. Although ROMs may seem like a good idea, that is just an implementation detail and is best left to the later stages of planning. This will have nothing to do with designing an instruction set. BTW, microcode really shines when you are designing a machine with lots of states. My CPU has one state, "Decode / Execute&Fetch". The decode is done first and the execute and fetch are done in parallel, all in the same clock cycle. There are no states, it just continues to update the instruction pointer and register on each clock cycle and the rest of the chip functions according to what is in the instruction register. > I still think the most important thing you should do is write > lots of code so you have some samples to feed to the tools > and get some real numbers. I agree, but I was hoping to find code rather than having to write it first. Maybe you are right and instead of working on the CPU, I should start writing code and working on the tools for that. RickArticle: 137107
Jan wrote: > jeremywwebb@gmail.com wrote: > Ok, after trying to add the port in the MHS file it showed up in the > assembly view. Now a new problem appeared. I don't know how to map the > new port to a physical port. Where can I add new locations that then can > be selected in the assembly view? Either the texteditor-way: (Edit .ucf and .mhs by hand) or the official way: edit .ucf and create an external port (by mind i'd say there is a button in the right upper corner of the system assembly view (ports tab)) Alternatively You can click on the peripheral's port and get a drop-down-combo where you can click on "make external". > > Regards > Jan Regards, LorenzArticle: 137108
On Dec 23, 11:54=A0am, Lorenz Kolb <lorenz.k...@uni-ulm.de> wrote: > santhosh_h...@yahoo.com wrote: > > Hi, > > > I know DFF is: > > > module DFF(d,clk,q) ; > > =A0 =A0 =A0input d, clk ; > > =A0 =A0 =A0output reg q ; > > > =A0 =A0 =A0always @(posedge clk) > > =A0 =A0 =A0 =A0 =A0 =A0q<=3D d ; > > endmodule > > > Now I need to implement ASYNCHRONOUS RESET flip flop > > using DFF ONLY, may be some extract logic. HOW CAN I DO THAT ? > > > The implemented circuit MUST WORK AS FOLLOWS: > > > module DFFR(d,clk,r, q) ; > > =A0 =A0 =A0input d, clk,r ; > > =A0 =A0 =A0output reg q ; > > > =A0 =A0 =A0always @(posedge clk or posedge r) > > =A0 =A0 =A0 =A0 =A0 if (r) q <=3D 0 ; > > =A0 =A0 =A0 =A0 =A0 else =A0q<=3D d ; > > endmodule > > > Please give the code or diagram. I am curious about this. > > Well actually that'll cost logic in the clock path. You'll most likely > have to create an own clock clk_dffr which is clk or rst; and you'll > need d_dffr which will be d and not rst. > > That should solve the task (though I'm not happy about that solution, > but no better one came to my mind). > > > Sant > > Regards, > > Lorenz Even then you would need to ensure adequate setup time on the D input when resetting. Assuming D was otherwise high, d_dffr and clk_dffr would change at the same time unless you made extra delay in the clock path. And of course you need to make sure that your path from the standard D input still has hold time after all of the gating... Good luck, GaborArticle: 137109
On Dec 23, 9:18=A0am, Karl <karl.polyt...@googlemail.com> wrote: > Hi, > I have to map some scientific application algorithms on FPGA using a > High Level Language (HLL) and not VHDL. I am lost regarding the choice > of the HLL language to use which not only allows efficient mapping but > also the user to alter and enhance the compiler and the mapping in > general, preferably open source compiler! > > I got conflicting feedbacks about Mitrion-C in particular which i was > using to use. some suggested Handel-C other Mitrion-C, etc...i could > not find a rigourous comparative studies. could you share your > experience with us and/or any advice I am curious about what you are planning to do. When you talk about altering the "mapping" what does that mean? If you are looking to use an algorithm written in C as source code for an FPGA design, I don't know that adjusting the "mapping" is going to work for you. Typically an algorithm has to be ported to an FPGA. If the algorithm is written starting with the idea of using it in an FPGA then the code may compile ok. But if it was not, it is unlikely to be compilable at all or at best produce an inefficient design. Software is normally written to be executed sequentially on a processor. FPGAs can also do that, but for the most part they provide parallel execution on dedicated hardware. To efficiently design in an FPGA this difference needs to be addressed and computers are not very good at doing this yet. A designer is best for that job. BTW, you didn't explain what HPC stands for. I know what HPLC is. RickArticle: 137110
>> > Now I need to implement ASYNCHRONOUS RESET flip flop >> > using DFF ONLY, may be some extract logic. HOW CAN I DO THAT ? >> >> > The implemented circuit MUST WORK AS FOLLOWS: >> >> > module DFFR(d,clk,r, q) ; >> > input d, clk,r ; >> > output reg q ; >> >> > always @(posedge clk or posedge r) >> > if (r) q <= 0 ; >> > else q<= d ; >> > endmodule >> >> > Please give the code or diagram. I am curious about this. The thing I'm curious about is WHY? Gabor is right about the extreme difficulty of getting something that works correctly if you try to gate reset and clock together. If you're allowed any amount of combinational logic in addition to DFF, which I assume is the case, then you could consider this idea, (c)2008 Santa's Elves, to be enjoyed in moderation with a vomit-bag handy: module DFFR(input d, clk, r, output q); // wire d_int, q_int, flipper; // // Here's the main FF. Its output is inverted // if necessary to give reset behaviour. DFF data_ff(.d(d_int), .clk(clk), .q(q_int)); assign q = q_int ^ flipper; // // The second FF captures the data FF's output // when reset happens, and uses that captured // value to invert the main FF's output if necessary. DFF flipper_ff(.d(q_int), .clk(r), .q(flipper); // // Finally, we invert the D input to the main FF // to match the inversion of its output. But we // also disable clocking of this FF while reset // is active, so that we don't need to worry about // the reset value at any time other than (posedge r). assign d_int = r? q_int: d ^ flipper; // endmodule This is still exposed to a race between active edges of clock and reset, but otherwise I think it works; and it doesn't corrupt the hold time behaviour of the main (data_ff) flop. Actually, on mature reflection I think this one is (c)2008 The Grinch. Season's Greetings to all :-) -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 137111
On Dec 23, 1:20=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > >> > Now I need to implement ASYNCHRONOUS RESET flip flop > >> > using DFF ONLY, may be some extract logic. HOW CAN I DO THAT ? > > >> > The implemented circuit MUST WORK AS FOLLOWS: > > >> > module DFFR(d,clk,r, q) ; > >> > =A0 =A0 =A0input d, clk,r ; > >> > =A0 =A0 =A0output reg q ; > > >> > =A0 =A0 =A0always @(posedge clk or posedge r) > >> > =A0 =A0 =A0 =A0 =A0 if (r) q <=3D 0 ; > >> > =A0 =A0 =A0 =A0 =A0 else =A0q<=3D d ; > >> > endmodule > > >> > Please give the code or diagram. I am curious about this. > > The thing I'm curious about is WHY? > > Gabor is right about the extreme difficulty of getting > something that works correctly if you try to gate reset > and clock together. > > If you're allowed any amount of combinational logic > in addition to DFF, which I assume is the case, then > you could consider this idea, (c)2008 Santa's Elves, > to be enjoyed in moderation with a vomit-bag handy: > > module DFFR(input d, clk, r, output q); > =A0 // > =A0 wire d_int, q_int, flipper; > =A0 // > =A0 // Here's the main FF. =A0Its output is inverted > =A0 // if necessary to give reset behaviour. > =A0 DFF data_ff(.d(d_int), .clk(clk), .q(q_int)); > =A0 assign q =3D q_int ^ flipper; > =A0 // > =A0 // The second FF captures the data FF's output > =A0 // when reset happens, and uses that captured > =A0 // value to invert the main FF's output if necessary. > =A0 DFF flipper_ff(.d(q_int), .clk(r), .q(flipper); > =A0 // > =A0 // Finally, we invert the D input to the main FF > =A0 // to match the inversion of its output. =A0But we > =A0 // also disable clocking of this FF while reset > =A0 // is active, so that we don't need to worry about > =A0 // the reset value at any time other than (posedge r). > =A0 assign d_int =3D r? q_int: d ^ flipper; > =A0 // > endmodule > > This is still exposed to a race between active edges > of clock and reset, but otherwise I think it works; > and it doesn't corrupt the hold time behaviour of the > main (data_ff) flop. > > Actually, on mature reflection I think this one is > (c)2008 The Grinch. > > Season's Greetings to all :-) > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. Wow! My head is spinning! It seems to me if you want to use the gated Q approach, you don't really need a "flipper" but only an AND gate since reset can only drive the Q output low. If you made an internal reset signal, on while "r" is asserted and held until the data flip-flop Q output is low, you can gate this into the d input of the data flip-flop as a synchronous reset, and also gate it with Q to make the reset appear asynchronous. You wouldn't need a proper D flip-flop for the reset signal, just an implied latch like: r_int =3D r | r_int & q_int; then d_int =3D d & !r_int; q =3D q_int & !r_int; Cheers, GaborArticle: 137112
On Dec 23, 1:50=A0am, "Andrew W. Hill" <aquaregi...@gmail.com> wrote: > All, > I'm using EDK 10.1, specced for the ML501. =A0When I reach the mapping > phase, I get the following error (several times): > > ERROR:PhysDesignRules:1492 - Incompatible programming for comp > mb_plb_M_ABus<1>. > =A0 =A0The pair of luts SLICEL_A5LUT and SLICEL_A6LUT must have a > compatible > =A0 =A0equation, lower bits must be programmed the same. The SLICEL_A5LUT > hex > =A0 =A0equation is <O5=3D0x08080808> and the SLICEL_A6LUT hex equation is > =A0 =A0<O6=3D0x607AA67800008888>. > > I found the following Xilinx note on the error, which notes that this > error was erroneously thrown in EDK versions <8 :http://www.xilinx.com/su= pport/answers/23645.htm > > My system is fairly standard. =A0I used BSB and added a few things > (LEDs,switches), but nothing particularly exotic. Is there something > obvious that I might have missed, or is this likely to be an error > with DRC? > > Thanks > Andrew The obvious question, given the note from Xilinx, is did you ever build any part of this system under an older revision of EDK? Xilinx software is famous for failing to clean up old bits of object...Article: 137113
I >Gabor is right about the extreme difficulty of getting >something that works correctly if you try to gate reset >and clock together. > >If you're allowed any amount of combinational logic >in addition to DFF, which I assume is the case, then >you could consider this idea, (c)2008 Santa's Elves, >to be enjoyed in moderation with a vomit-bag handy: If you have unlimited gates, why not just ignore the DFF? Old data books gave gate level diagrams for things like FFs. Here is an example: http://focus.ti.com/lit/ds/symlink/sn74ls74a.pdf An edge triggered FF is two latches. A latch is a pair of cross coupled gates. Set/Reset are just another term into some of the gates. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 137114
On Dec 23, 11:15 am, Gabor <ga...@alacron.com> wrote: > On Dec 23, 1:50 am, "Andrew W. Hill" <aquaregi...@gmail.com> wrote: > > I'm using EDK 10.1, specced for the ML501. When I reach the mapping > > phase, I get the following error (several times): > > > ERROR:PhysDesignRules:1492 - Incompatible programming for comp > > mb_plb_M_ABus<1>. > > The pair of luts SLICEL_A5LUT and SLICEL_A6LUT must have a > > compatible > > equation, lower bits must be programmed the same. The SLICEL_A5LUT > > hex > > equation is <O5=0x08080808> and the SLICEL_A6LUT hex equation is > > <O6=0x607AA67800008888>. > > > I found the following Xilinx note on the error, which notes that this > > error was erroneously thrown in EDK versions <8 :http://www.xilinx.com/support/answers/23645.htm > > > My system is fairly standard. I used BSB and added a few things > > (LEDs,switches), but nothing particularly exotic. Is there something > > obvious that I might have missed, or is this likely to be an error > > with DRC? > > The obvious question, given the note from Xilinx, is did you ever > build > any part of this system under an older revision of EDK? Xilinx > software > is famous for failing to clean up old bits of object... I previously built under EDK 9, but I did a clean from within EDK and also did a quick walkthrough of the remaining files. I've never built it in EDK <8. Cheers AndrewArticle: 137115
On Tue, 23 Dec 2008 18:20:50 +0000, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote: >This is still exposed to a race between active edges >of clock and reset, but otherwise I think it works; >and it doesn't corrupt the hold time behaviour of the >main (data_ff) flop. How is this any different from a DFFR ie a DFF with built-in async reset? One has to meet the reset removal timing in a DFFR which is the same problem with your solution above. Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 137116
On Tue, 23 Dec 2008 11:12:45 -0800 (PST), gabor <gabor@alacron.com> wrote: >It seems to me if you want to use the gated Q approach, you >don't really need a "flipper" but only an AND gate since >reset can only drive the Q output low. If you made an >internal reset signal, on while "r" is asserted and >held until the data flip-flop Q output is low, you can >gate this into the d input of the data flip-flop as >a synchronous reset, and also gate it with Q to make the >reset appear asynchronous. You wouldn't need a proper >D flip-flop for the reset signal, just an implied >latch like: > >r_int = r | r_int & q_int; > >then > >d_int = d & !r_int; > >q = q_int & !r_int; This doesn't solve the problem perfectly. A real async reset flop doesn't need a clock edge to reset the internal state of the flop so if a reset arrives and leaves before any clock edges appear the Q of the flop changes to and stays at 0. In the case above the you have no control over q_int which is presumably X in this condition so when you remove reset q will go back to X which is what the async reset was trying to solve after all. Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 137117
On Dec 23, 3:25=A0pm, Muzaffer Kal <k...@dspia.com> wrote: > On Tue, 23 Dec 2008 11:12:45 -0800 (PST), gabor <ga...@alacron.com> > wrote: > > > > >It seems to me if you want to use the gated Q approach, you > >don't really need a "flipper" but only an AND gate since > >reset can only drive the Q output low. =A0If you made an > >internal reset signal, on while "r" is asserted and > >held until the data flip-flop Q output is low, you can > >gate this into the d input of the data flip-flop as > >a synchronous reset, and also gate it with Q to make the > >reset appear asynchronous. =A0You wouldn't need a proper > >D flip-flop for the reset signal, just an implied > >latch like: > > >r_int =3D r | r_int & q_int; > > >then > > >d_int =3D d & !r_int; > > >q =3D q_int & !r_int; > > This doesn't solve the problem perfectly. A real async reset flop > doesn't need a clock edge to reset the internal state of the flop so > if a reset arrives and leaves before any clock edges appear the Q of > the flop changes to and stays at 0. In the case above the you have no > control over q_int which is presumably X in this condition so when you > remove reset q will go back to X which is what the async reset was > trying to solve after all. > > Muzaffer Kal > > DSPIA INC. > ASIC/FPGA Design Serviceshttp://www.dspia.com Well actually that is why r_int is held until q_int goes low. This guarantees that the next clock edge after reset also clocks the Q low. The down side to this of course is that it doesn't actually model a D flip-flop with async reset, which could possibly go high on the first edge after reset is released.Article: 137118
On Tue, 23 Dec 2008 12:46:45 -0800 (PST), Gabor <gabor@alacron.com> wrote: >On Dec 23, 3:25 pm, Muzaffer Kal <k...@dspia.com> wrote: >> On Tue, 23 Dec 2008 11:12:45 -0800 (PST), gabor <ga...@alacron.com> >> wrote: >> >> >> >> >It seems to me if you want to use the gated Q approach, you >> >don't really need a "flipper" but only an AND gate since >> >reset can only drive the Q output low. If you made an >> >internal reset signal, on while "r" is asserted and >> >held until the data flip-flop Q output is low, you can >> >gate this into the d input of the data flip-flop as >> >a synchronous reset, and also gate it with Q to make the >> >reset appear asynchronous. You wouldn't need a proper >> >D flip-flop for the reset signal, just an implied >> >latch like: >> >> >r_int = r | r_int & q_int; >> >> >then >> >> >d_int = d & !r_int; >> >> >q = q_int & !r_int; >> >> This doesn't solve the problem perfectly. A real async reset flop >> doesn't need a clock edge to reset the internal state of the flop so >> if a reset arrives and leaves before any clock edges appear the Q of >> the flop changes to and stays at 0. In the case above the you have no >> control over q_int which is presumably X in this condition so when you >> remove reset q will go back to X which is what the async reset was >> trying to solve after all. >> >> Muzaffer Kal >> >> DSPIA INC. >> ASIC/FPGA Design Services >> http://www.dspia.com > >Well actually that is why r_int is held until q_int goes >low. This guarantees that the next clock edge after reset >also clocks the Q low. The down side to this of course >is that it doesn't actually model a D flip-flop with >async reset, which could possibly go high on the first >edge after reset is released. I think the down side is a little more than that. If q_int is X (which is what one should expect for a flop with no async controls), "r_int & q_int" is also X. So when r goes high then low, r_int is 1 then X. I don't think you're getting the latching affect you're looking for; in Verilog simulation anyway. Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 137119
On Tue, 23 Dec 2008 12:19:34 -0800, Muzaffer Kal <kal@dspia.com> wrote: >On Tue, 23 Dec 2008 18:20:50 +0000, Jonathan Bromley wrote: > >>This [...devil's-spawn I proposed for a DFFR made only from DFFs and gates] >>is still exposed to a race between active edges >>of clock and reset > >How is this any different from a DFFR ie a DFF with built-in async >reset? One has to meet the reset removal timing in a DFFR which is the >same problem with your solution above. The problem isn't removal/recovery. It's at the *assertion* of reset, when the "flipper" DFF captures the current state of the data FF. If the data FF changes state at the same time, thanks to a simultaneous clock edge, the flipper can hold the wrong value and the whole mess might reset to 1 instead of 0. A conventional DFFR model doesn't suffer from such a race, and nor does the real thing. It's easy to fix by introducing a non-zero time delay in the clock path to the flipper DFF's clock. But then the whole thing could fail if there's a reset pulse shorter than that time delay. I don't think there is any way out that is completely bombproof. Of course, as someone else pointed out, you can do the whole thing with a gate-level model of a master-slave flip-flop, or something similar. I didn't feel that was in the spirit of the original rather bizarre question, so provided instead my correspondingly bizarre solution. I still think it goes rather well with the mince pies, plum pudding and other general Yuletide excesses: On the first day of Christmas my client sent to me a skew-ridden gated clock tree. On the second day of Christmas my client sent to me two setup failures and a skew-ridden gated clock tree. On the third day.... bah, humbug, you get the general idea. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 137120
On Tue, 23 Dec 2008 22:46:22 +0000, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote: >On Tue, 23 Dec 2008 12:19:34 -0800, Muzaffer Kal <kal@dspia.com> >wrote: > >>On Tue, 23 Dec 2008 18:20:50 +0000, Jonathan Bromley wrote: >> >>>This > >[...devil's-spawn I proposed for a DFFR made only from >DFFs and gates] > >>>is still exposed to a race between active edges >>>of clock and reset >> >>How is this any different from a DFFR ie a DFF with built-in async >>reset? One has to meet the reset removal timing in a DFFR which is the >>same problem with your solution above. > >The problem isn't removal/recovery. It's at the *assertion* >of reset, when the "flipper" DFF captures the current state >of the data FF. If the data FF changes state at the same >time, thanks to a simultaneous clock edge, the flipper can >hold the wrong value and the whole mess might reset to 1 >instead of 0. A conventional DFFR model doesn't suffer >from such a race, and nor does the real thing. Actually I think there is another issue with the model. It is possible that the reset will start high at the start of the simulation and there won't be a posedge for the flipper flop to see. I am not sure if the model handles that case correctly. Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 137121
Thanks Rick for your reply. Sorry for not being so clear. HPC was a reference to High Performance Computing. I want to use a high level language to implement some legacy codes: common HPC packages (e.g. numerical libraries, statistical packages) and specialised software (e.g. in computational biology) on FPGA. I want to investigate how good FPGA can be in implementing floating point based algorithms as well as doing some research in hardware compilation. as such i want to use a high level language which permits the integration of some add-in by the developer (that;s why i said a language which allows the user to improve on the mapping of the algorithms on FPGA) as i know these high level languages are not yet too efficient and don't want to be bound by their current limitations. what language could be best? what about xilinx Chimps? CheersArticle: 137122
Karl <karl.polytech@googlemail.com> wrote: > Thanks Rick for your reply. Sorry for not being so clear. HPC was a > reference to High Performance Computing. I want to use a high level > language to implement some legacy codes: common HPC packages (e.g. > numerical libraries, statistical packages) and specialised software > (e.g. in computational biology) on FPGA. Most computational biology is done fixed point, which works very well in FPGAs. Floating point tends to take up a lot of space in an FPGA, especially the normalization logic needed for addition. In many cases adders are bigger than multipliers. > I want to investigate how > good FPGA can be in implementing floating point based algorithms as > well as doing some research in hardware compilation. as such i want to > use a high level language which permits the integration of some add-in > by the developer (that;s why i said a language which allows the user > to improve on the mapping of the algorithms on FPGA) as i know these > high level languages are not yet too efficient and don't want to be > bound by their current limitations. what language could be best? what > about xilinx Chimps? The systolic array architecture is often used for FPGA based algorithms, in both fixed and floating point. -- glenArticle: 137123
On Dec 23, 7:27 pm, Karl <karl.polyt...@googlemail.com> wrote: > Thanks Rick for your reply. Sorry for not being so clear. HPC was a > reference to High Performance Computing. I want to use a high level > language to implement some legacy codes: common HPC packages (e.g. > numerical libraries, statistical packages) and specialised software > (e.g. in computational biology) on FPGA. I want to investigate how > good FPGA can be in implementing floating point based algorithms as > well as doing some research in hardware compilation. as such i want to > use a high level language which permits the integration of some add-in > by the developer (that;s why i said a language which allows the user > to improve on the mapping of the algorithms on FPGA) as i know these > high level languages are not yet too efficient and don't want to be > bound by their current limitations. what language could be best? what > about xilinx Chimps? I think what I said before still applies. You have algorithms written in a software language. Most software programming languages are designed for sequential processing. I expect all of your code is written in this manner. An FPGA does not do anything better than a processor can do, in fact they are typically slower in any given activity. But while a processor executes the steps sequentially an FPGA can perform things in parallel. If you code an FFT butterfly, for example, it uses multiple complex multiplies and adds. A processor has to do each step sequentially. A specialized processor can perform a couple of multiplies and adds simultaneously, but the algorithm is still sequential. An FPGA can be programmed to do all the steps at the same time to produce a butterfly result on each clock cycle. Or you can even build multiple butterfly units to perform many butterflies in parallel. Or an FPGA can be programmed to perform the FFT and the FIR filter in parallel and so on. Here is the "BUT": HDL is short for hardware description language. Notice it is *not* called a programming language. That is because you are not programming a processor. You are describing the hardware that will do the processing. There is a big difference. I am not overly familiar with designing hardware in the C language, but from what I have read, C is not used as an HDL in the same way as it is to write a program. The coding style has to use a specific structure that can be recognized and translated into hardware. So if you want to use a C compiler or Verilog or VHDL, you need to understand that you can't just take a software program and have a tool turn it into hardware. At least I don't think you can. I also am pretty sure that you can't easily write an add-in to make this translation. Doing so would be such a significant advance that it would have been done by now. Please don't let my words be a wet blanket to your ideas. I am just trying to present the current state of the tools realistically. If the point of your research is to develop advanced tools, then by all means proceed. But if your goal is to port HPC programs to FPGAs, then you need to understand what is involved. By that I mean you should start with an existing tool and learn how to write HDL without modifying the tool. Only then will you have an idea of how to start porting code from a programming language to an HDL. Then perhaps you can figure out ways to improved the tools. As to which tool, I can't say anything about the open source C based tools. I understand there is a fairly good Verilog tool called Icarus. That might be a good place to start. RickArticle: 137124
> what about xilinx Chimps? BTW, I don't think Xilinx makes Chimps... ;^) 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