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
On Aug 14, 10:24 am, moo...@yahoo.co.uk wrote:
> Hi,
>
> I wonder if anyone has seen something like this.
>
> I have an FPGA design targeted at an Spartan xc3s1500 and using
> ISE8.2.
>
> We are using a spartan evaluation board with some 7 segment LED's.
>
> If I make minor changes to the pinout, sometimes the FPGA stops
> functioning completely. What is interesting, is that the 7 segment
> LED's are not driven. The VHDL code for this is :
>
> p_seven_seg : process(clk system_reset_n,)
>
> begin
> if(system_reset_n = '0')then
> seven_seg_1 <= "1111111";
> elsif(clk = '1'and clkt'event) then
> case (conv_integer(p1)) is
> when 0 =>
> seven_seg_1 <= not("0111111");
> when others =>
> seven_seg_1 <= "1111111";
> end case;
My guess is that you're downloading the bitstream, watching it work,
making a small change, downloading it again, etc., etc.
There are situations where the second (and subsequent) bit stream
loads just don't work. This depends mostly on your programming method
and hardware.
Try removing the power from the FPGA completely before doing bitstream
loads.
G.
Article: 123026<moogyd@yahoo.co.uk> wrote in message news:1187112403.482357.230890@d55g2000hsg.googlegroups.com... > > We are using a spartan evaluation board with some 7 segment LED's. > > If I make minor changes to the pinout, sometimes the FPGA stops > functioning completely. What is interesting, is that the 7 segment > LED's are not driven. > > > Steven > Hi Steven, Your VHDL is missing an 'end if' I think, and you should use numeric.std, it's much nicer. Have you 'loc'ked all the pins in your design? Does your design meet the timing? HTH., Syms.Article: 123027
Hi I have designed an SDRAM controller and nearly ready to synth and P&R. My question is do I need to add any offset constraints to the ucf? I see that the Xilinx XAPP134 uses them but the newer DDR designs which are generated using MIG do not. Any info would be appreciated? Cheers JonArticle: 123028
I have to delay a pulse train by a given number of clocks on the same domain as the pulse to be delayed. The best approach I can think of is to run a counter of sufficient width and log pulse transitions and states into a circular "pulse transition list" of sufficient depth. After waiting for the desired number of clock transitions (the delay) an output counter of the same width as the input sample counter is allowed to start counting. This counter is used to address the "pulse transition list" to generate a delayed output that matches the input. Using SelectRAM memory for delay is out of the question as too much memory would be required and it is needed elsewhere in the design. Can anyone suggest a better way to do this? The incoming pulses are relatively regular and can be of any duration, from a few clocks to hundreds. Thanks, -MartinArticle: 123029
Martin, have you thought of using the dual-ported BlockRAMs? Use a free-running counter to address one port, where you write the incoming data. Use another counter, appropriately offset, (or a subtractor) to read the data out on the other port. As long as the delay is shorter than the BRAM depth, this process can go on forever... Peter Alfke ============== On Aug 14, 11:52 am, m <martin.use...@gmail.com> wrote: > I have to delay a pulse train by a given number of clocks on the same > domain as the pulse to be delayed. > > The best approach I can think of is to run a counter of sufficient > width and log pulse transitions and states into a circular "pulse > transition list" of sufficient depth. After waiting for the desired > number of clock transitions (the delay) an output counter of the same > width as the input sample counter is allowed to start counting. This > counter is used to address the "pulse transition list" to generate a > delayed output that matches the input. > > Using SelectRAM memory for delay is out of the question as too much > memory would be required and it is needed elsewhere in the design. > > Can anyone suggest a better way to do this? The incoming pulses are > relatively regular and can be of any duration, from a few clocks to > hundreds. > > Thanks, > > -MartinArticle: 123030
> Martin, have you thought of using the dual-ported BlockRAMs? It would consume too many BRAMs. I need delays in the order of 500us at 150MHz. That's about 5 BRAMs (Virtex2). I need them for other portions of the design. It'd sure be easy though! -MArticle: 123031
On Aug 14, 12:24 pm, moo...@yahoo.co.uk wrote:
> Hi,
>
> I wonder if anyone has seen something like this.
>
> I have an FPGA design targeted at an Spartan xc3s1500 and using
> ISE8.2.
>
> We are using a spartan evaluation board with some 7 segment LED's.
>
> If I make minor changes to the pinout, sometimes the FPGA stops
> functioning completely.
-Just out of curiousity, why are you changing the pin outs?? For an
eval board, many pins are hard-wired to chips, LEDs, etc, and so the
pinouts must _not_ be changed! You do have flexibility if FPGA pins
are connected to expansion connectors.
>What is interesting, is that the 7 segment LED's are not driven. The VHDL code for this is :
>
> p_seven_seg : process(clk system_reset_n,)
>
> begin
> if(system_reset_n = '0')then
> seven_seg_1 <= "1111111";
> elsif(clk = '1'and clkt'event) then
> case (conv_integer(p1)) is
> when 0 =>
> seven_seg_1 <= not("0111111");
> when others =>
> seven_seg_1 <= "1111111";
> end case;
Bug 1 - p_seven_seg : process(clk system_reset_n,)
There should be a comma (,) between "clk" and "system_reset_n".
Remove the comma before ")".
Bug 2 - elsif(clk = '1' and clkt'event) then
OK, is the clock named "clk" or "clkt" ??
An alternate form is
elsif rising_edge(clk) then
HTH
-Dave Pollum
Article: 123032"m" <martin.usenet@gmail.com> wrote in message news:1187117559.671533.286940@i38g2000prf.googlegroups.com... >I have to delay a pulse train by a given number of clocks on the same > domain as the pulse to be delayed. > > The best approach I can think of is to run a counter of sufficient > width and log pulse transitions and states into a circular "pulse > transition list" of sufficient depth. After waiting for the desired > number of clock transitions (the delay) an output counter of the same > width as the input sample counter is allowed to start counting. This > counter is used to address the "pulse transition list" to generate a > delayed output that matches the input. > > Using SelectRAM memory for delay is out of the question as too much > memory would be required and it is needed elsewhere in the design. > > > Can anyone suggest a better way to do this? The incoming pulses are > relatively regular and can be of any duration, from a few clocks to > hundreds. > > Thanks, > > -Martin The entire delay can be "a few" to "hundreds" of clocks and the overall delay can be 500us*150MHz=75000 periods. How many pulses can be in transit at any one time? hundreds? Only one? The transition list might be the lowest-resource approach, especially when using SRLs to maintain the list. I'm just not sure if 16 (or 32 or 64) elements are enough for your needs. You'll need a 17 bit counter to reach 500 us at 150 MHz. It might be handy to guarantee clean operation by adding an 18th bit for pulse polarity. The number of entries you'll need is twice the number of pulses you must accommodate.Article: 123033
On 14 Aug, 21:16, Dave Pollum <vze24...@verizon.net> wrote:
> On Aug 14, 12:24 pm, moo...@yahoo.co.uk wrote:> Hi,
>
> > I wonder if anyone has seen something like this.
>
> > I have an FPGA design targeted at an Spartan xc3s1500 and using
> > ISE8.2.
>
> > We are using a spartan evaluation board with some 7 segment LED's.
>
> > If I make minor changes to the pinout, sometimes the FPGA stops
> > functioning completely.
>
> -Just out of curiousity, why are you changing the pin outs?? For an
> eval board, many pins are hard-wired to chips, LEDs, etc, and so the
> pinouts must _not_ be changed! You do have flexibility if FPGA pins
> are connected to expansion connectors.
>
> >What is interesting, is that the 7 segment LED's are not driven. The VHDL code for this is :
>
> > p_seven_seg : process(clk system_reset_n,)
>
> > begin
> > if(system_reset_n = '0')then
> > seven_seg_1 <= "1111111";
> > elsif(clk = '1'and clkt'event) then
> > case (conv_integer(p1)) is
> > when 0 =>
> > seven_seg_1 <= not("0111111");
> > when others =>
> > seven_seg_1 <= "1111111";
> > end case;
>
> Bug 1 - p_seven_seg : process(clk system_reset_n,)
> There should be a comma (,) between "clk" and "system_reset_n".
> Remove the comma before ")".
> Bug 2 - elsif(clk = '1' and clkt'event) then
> OK, is the clock named "clk" or "clkt" ??
> An alternate form is
> elsif rising_edge(clk) then
>
> HTH
> -Dave Pollum
Hi,
Sorry for the confusion - the VHDL was cut and pasted (and
simplified). I wanted to simply show how "simple" the functionality
that is not working. It does compile (and the FPGA works 90% of the
time)
Anyway, to other points, the eval board has expansion connectors where
we can add eval boards and connect to test equipment. This is why I
change the pinout.
The design is timing clean (which of course depends on me constraining
it correctly). However, even with timing problems I would expect the
above logic to at least drive the O/P's.
I haven't locked all I/O's down - I will try this tomorrow.
One more note. I have an O/P bus called DVDD. Is this likely to be an
issue for the Xilinx tool chain (it works most of the time).
Thanks,
Steven
Article: 123034Martin, to delay a 150 MHz bitstream by 500 us, you need to store 75000 bits. If you cannot afford that on-chip, you must store it off-chip. There is no other way, unless you are willing to think of data compression (Huffman?) Peter Alfke ============ On Aug 14, 12:10 pm, m <martin.use...@gmail.com> wrote: > > Martin, have you thought of using the dual-ported BlockRAMs? > > It would consume too many BRAMs. I need delays in the order of 500us > at 150MHz. That's about 5 BRAMs (Virtex2). I need them for other > portions of the design. > > It'd sure be easy though! > > -MArticle: 123035
I am using the MIG generated DDR2 controller in a V5 device. The DDR2 runs at 266 MHz. I am meeting timing, but I am finding the performance of the controller to be a little dissapointing. When I am reading and writing 128 byte chunks of data to random locations (usually a new row or bank), I am seeing about 28 % bus utilization, while my application really requires closer to 60 % under these conditions. I have two questions: 1) Have others seen this type of performance with the MIG generated DDR2 controller ? 2) Does anyone have experience with 3rd party IP that might come closer to the 60 % utilization I require. Thanks. -BruceArticle: 123036
"Peter Alfke" <peter@xilinx.com> wrote in message news:1187123107.324950.325860@x35g2000prf.googlegroups.com... > Martin, to delay a 150 MHz bitstream by 500 us, you need to store > 75000 bits. > If you cannot afford that on-chip, you must store it off-chip. > There is no other way, unless you are willing to think of data > compression (Huffman?) > Peter Alfke His original suggestion was to mark the edges on the input and replicate the edges to the output with a counter shifted by the needed delay, accumulating these transitions in a list. As long as the number of transitions in the delay is small (compared to 75k, at least) his suggested approach is wholly adequate.Article: 123037
> Martin, to delay a 150 MHz bitstream by 500 us, you need to store > 75000 bits. > If you cannot afford that on-chip, you must store it off-chip. > There is no other way, unless you are willing to think of data > compression (Huffman?) > Peter Alfke I have the module I described in the original post working just fine right now. So, for cases where the number of transitions during the delay period isn't excessive, yes, there is another way. I agree though, that, if the intent was to store any random pulse train you'd have no choice but to store and "replay" at a later time...requiring BRAM. -MArticle: 123038
Peter Alfke wrote: > Martin, to delay a 150 MHz bitstream by 500 us, you need to store > 75000 bits. > If you cannot afford that on-chip, you must store it off-chip. > There is no other way, unless you are willing to think of data > compression (Huffman?) I think his edge-tag scheme is valid and is often used in Logic Analysers, to get better apparent dynamic range. Of course it is more complex that a simple spinning delay buffer, but it may be the Logic/BRAM trade off is worth it ? -jgArticle: 123039
m wrote: >>Martin, have you thought of using the dual-ported BlockRAMs? > > > It would consume too many BRAMs. I need delays in the order of 500us > at 150MHz. That's about 5 BRAMs (Virtex2). I need them for other > portions of the design. > > It'd sure be easy though! What is your expected maximum edge count, in that 500us ? =jgArticle: 123040
Hi everyone, I am using Xilinx ISE simulator for behavioral simulation of a large circuit. I would like to save simulated results, to avoid running the simulation again, which takes quite some time. However, when I use the "Save As" in Xilinx ISE, it DOES NOT save the results. I don't see any other options that would allow me to save data. My ISE version is 8.2.03i Any help would be greatly appreciated. Thanks! TeleArticle: 123041
Huffman run-length encoding has been used successfully in early- generation fax machines. Whether that or any other compression (e.g. edge-detection) scheme is good, depends on the characteristics of the bitstream in question. Peter AlfkeArticle: 123042
I keep running into a System ACE problem on the ML405 when trying to get my own ACE file to load. - I've properly formatted the CF card (as described in Answer Records #14456), and I've verified this by copying the demo files over and booting into them. The demos work fine, but when I select the custom ACE file from the menu, it fails and the ERR led turns on. - I've generated the files using the genace.tcl script provided with the ml405 reference design (it contains the correct JTAG sequence for that board). I've verified that the JTAG chain setup in genace is correct (against what I read via iMPACT). I've tried using both system.bit and the ELF-infused download.bit as the basis; both fail. - I've replaced the old genace.tcl file in \EDK\data\xmd with the new one that has the ml405's board information, and tried generating through XPS, also to no avail - Directly from iMPACT, I created an ACE file. I tried this on a clean format of the CF, using one revision at 0, and I still got the same result. - I'm using EDK 8.2 SP3 on Windows 2000; using a 512 MB CF disk with a 95 MB FAT16 partition (the rest is the factory-shipped Linux partition) Is there anything specific in the actual bitstream that I may be missing? e.g. does my bitstream need a System ACE controller? Thanks, KunalArticle: 123043
What does this "PACKER" warning
mean?
Lut _ driving carry _ can not
be packed with the carry due
to conflict with the common
signal requirement between Lut
inputs and the Carry DI/MAND pins.
This would result in an extra Lut
for a feedthrough.
Here is the VHDL code:
count_int_proc:process(clk)
begin
if(clk'event and clk='1')then
if(reset='1')then
count_int <= start_value;
elsif( enable='1') then
if(up='1' and count_int<max)then
count_int<=count_int+1;
elsif( down='1'and count_int>0) then
count_int<=count_int-1;
end if;
end if;
end if;
end process;
Thanks,
Brad Smallridge
AI Vision
Article: 123044On Aug 14, 3:42 pm, Peter Alfke <pe...@xilinx.com> wrote: > Huffman run-length encoding has been used successfully in early- > generation fax machines. > Whether that or any other compression (e.g. edge-detection) scheme is > good, depends on the characteristics of the bitstream in question. > Peter Alfke I should have also mentioned that there's a need to delay more than one such pulse streams (at least four). That would require about twenty 18K BRAMS...I use that many without going to a significantly larger device. -MArticle: 123045
m wrote: > On Aug 14, 3:42 pm, Peter Alfke <pe...@xilinx.com> wrote: > >>Huffman run-length encoding has been used successfully in early- >>generation fax machines. >>Whether that or any other compression (e.g. edge-detection) scheme is >>good, depends on the characteristics of the bitstream in question. >>Peter Alfke > > > I should have also mentioned that there's a need to delay more than > one such pulse streams (at least four). That would require about > twenty 18K BRAMS...I use that many without going to a significantly > larger device. If you have the time-headroom, you might be able to compress what you have now, with a simple dictionary type lookup, and a dT storage. One more level of lookup, but the average storage/edge can drop. How many bits do you store now, per edge ? -jgArticle: 123046
If run-length (Huffman) encoding is not your favorite, you might think about one external SRAM for all four bitstreams. You could go byte- wide which reduces the frequency, then time-multiplex the two ports, so that you only need a 6-ns cycle-time relatively small external SRAM. This assumes that you four bitstreams use a common clock. The possibilities are endless... Peter Alfke On Aug 14, 6:17 pm, m <martin.use...@gmail.com> wrote: > I should have also mentioned that there's a need to delay more than > one such pulse streams (at least four). That would require about > twenty 18K BRAMS...I use that many without going to a significantly > larger device. > > -MArticle: 123047
I tried this, however this still doesn't work. I started xst now from the console and now I see that I get a memory violation at that certain point. I will use Precision from Mentor Graphics from now on for the synthesis. Matthias Brian Drummond schrieb: > On Tue, 14 Aug 2007 12:32:30 +0200, Matthias Alles > <REMOVEallesCAPITALS@NOeit.SPAMuni-kl.de> wrote: > >> There is nothing of interest in the output: >> >> INFO:Xst:2261 - The FF/Latch <configure.parallelism_2> in Unit <hws> is >> equivalent to the following 155 FFs/Latches, which will be removed : > > > Anything in the synthesis report file (.syr)? > > Since the error appears to be near register removal, it may be worth > turning OFF "equivalent register removal" and seeing if the error > remains. > > - BrianArticle: 123048
Hi Kunal, On 15 Aug., 02:38, Kunal <kunals.spam.acco...@gmail.com> wrote: > I keep running into a System ACE problem on the ML405 when trying to > get my own ACE file to load. > > - I've properly formatted the CF card (as described in Answer Records > #14456), and I've verified this by copying the demo files over and > booting into them. The demos work fine, but when I select the custom > ACE file from the menu, it fails and the ERR led turns on. I gather from this that your board actually has a System ACE controller which is able to configure your FPGA using the Compact Flash card as input. > - I've generated the files using the genace.tcl script provided with > the ml405 reference design (it contains the correct JTAG sequence for > that board). I've verified that the JTAG chain setup in genace is > correct (against what I read via iMPACT). I've tried using both > system.bit and the ELF-infused download.bit as the basis; both fail. What application (ELF file) are you using for download.bit? You should use download.bit and it should contain the bootloop. > - I've replaced the old genace.tcl file in \EDK\data\xmd with the new > one that has the ml405's board information, and tried generating > through XPS, also to no avail No idea what the difference is between those files. What is your memory setup? Do you by chance use any instruction memory? (isocm_cntrl or something like that) > - Directly from iMPACT, I created an ACE file. I tried this on a clean > format of the CF, using one revision at 0, and I still got the same > result. iMPACT failed on me as well so that's nothing special ;-) > Is there anything specific in the actual bitstream that I may be > missing? e.g. does my bitstream need a System ACE controller? I think the board has System ACE? How else do you load the ACE files? Greetings, TorstenArticle: 123049
On 15 Aug., 02:38, Kunal <kunals.spam.acco...@gmail.com> wrote: > I keep running into a System ACE problem on the ML405 when trying to > get my own ACE file to load. > > - I've properly formatted the CF card (as described in Answer Records > #14456), and I've verified this by copying the demo files over and > booting into them. The demos work fine, but when I select the custom > ACE file from the menu, it fails and the ERR led turns on. Try the well hidden AR 25046 http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=25046 Kolja Sulimma
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