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
Hi I am writing some C codes for Microblazes on EDK. Problem is that If I do not change the header file, it works fine. But, when I modify some parameters (for example, #define, or in-line function body ) in the user defiend header file, the system does not work. When I look at 'Directory' tab in "Compiler option", "Search path" and "Linker option" are empty. Only "Output information" contains the location of ELF file. Can anyone point me out what I am missing?Article: 113576
Daniel, why do you want to avoid the Gray register? Your design is at least as complicated and expensive, and incurs all this latency. Why do it, when there are simpler ways to avoid it? Peter Alfke On Dec 17, 7:30 am, "Daniel S." <digitalmastrmind_no_s...@hotmail.com> wrote: > There is a simple way of avoiding "mysterious glitches" when using > binary counters: freeze the counter in a second register in the first > clock domain and do a one bit handshake across the two domains. Since > the counter (copy) is frozen during the handshaking, the other clock > domain's FFs will have ample setup time until the strobe propagates > through the resync. > > With a fully resync'd handshake, this approach does introduce up to 3x > clock1 + 1.5x clock2 cycles delay between update, which is certainly not > suitable for low-latency and small high-speed FIFOs, especially if there > is a large difference in clock speeds. It works well as long as one can > live with long status delays for the first (read) and last (write) few > FIFO words. > > The design is nice as long as clocks are of similar frequencies but the > delay may become an issue for large read:write (and vice-versa) clock > ratios. At 10:1, the status update may have a latency exceeding 40 fast > clock cycles. > > So, binary counters can be safely used by using frozen copies and > handshaking. The caveat is higher latency than gray counters due to > handshaking and register copies that add extra dependencies upon the > other clock domain. > > As always, designers are free to pick their poison. > > Peter Alfke wrote: > > In an asynchronous FIFO, reading and writing is controlled by two > > counters with independent clocks. > > If you need to detect FULL or EMPTY, you compare the two counters for > > identity. > > If you do that with binary counters, you are vulnerable to strange > > decoding glitches, while multiple binary bits change (almost, but not > > quite, simultaneously). You never have that problem with Gray counters, > > where only one bit changes, from one state to the next. > > Peter Alfke > > ============= > > RCIngham wrote: > >>> There is a wrong way and a right way to convert binary to Gray count > >>> values: > >>> The wrong way hangs the (simple!) combinatorial conversion logic (XORs) > >>> on the binary outputs. That does you no good, since the Gray code will > >>> just reflect the binary transient errors. > >>> The right way takes the D inputs of the binary counter (, converts them > >>> independently to Gray and registers them in their own flip-flops. Now > >>> you have two parallel rgisters, both counting in step, the first in > >>> binary, the other in Gray, and there are no funny decoding spikes. > >>> BTW, only Gray counter outputs have the feature that you can compare > >>> two asynchronous counters for identity, without transient errors. > >>> If the Gray code does not come from a counter, it might change multiple > >>> bits per transition... > >> <snip /> > >> Whether that is the right answer rather depends on WHY the OP "has" to use > >> Gray Code, which is still not fully established. > > >> BTW, there is a quite interesting article on Gray Code just posted at: > >>http://www.pldesignline.com/showArticle.jhtml?articleID=196604078Article: 113577
Vangelis wrote: > I am trying to import a PowerPC design from EDK 7.1 to ISE 7.1 Project Navigator. While the design is working just fine when I download it from EDK, when I am trying to synthesize it in ISE and then download it to the FPGA nothing happens. It seems like the processor has no code to execute. In Project Navigator I generate the bitstream first and then I am updating the bitstream with processor data, just as the manual of the EDK mentions. Has anyone else the same problem? It is most likely that the problem is in the .bmm file. the ISE 7.1 places it in a wrong position, it should be related to your top module. Also make sure that the path to the memories inside the .bmm file is correct. I hope it helps.. Mordehay.Article: 113578
> > The short answer is 'NO' > > > > I can see a few issues. Do you need a 50% duty cycle on the output > > clock? That would bring up another issue. Can you please explain why I will not have 50% duty cycle? > > > > I'll be generous and assume this is not homework, but if it is, realise No. > > you're not really learning anything if you don't make your own mistakes; > > that way the lesson sticks ;) > > > > > > //divide oscillator clock by 10 (xc9536) > > module clk_div10 (in,out) > > input in; // input clock > > output out; // output clock = input/10 > > reg[0..3] cnt; > > > > assign out = cnt[3]; // map MSB to output - previous code > > needed a reg statement, which may or may not have been absorbed. Please explain, what is the purpose of this? > > // always @ (in) > > always @ (posedge in) // use the edge. The previous statement was > > a //static sensitivity list, as used in > > // combinational assignments Please explain why I should use the edge-trigger logic rather than combinational statements? > > begin > > // cnt=cnt+1; // let's not use a blocking assignment > > > // > if (cnt[3] & (cnt[2:0])) // test for increment > if (cnt[3] & (&cnt[2:0])) // test for increment - fixed > > or // reset at top > > begin > > cnt <= 4'b0; // count == 9 normally, and What is happening here, why are you testing up to 4 and not 9 ? > > also //guarantees > > // to move the counter to a valid state if it > > // somehow was in the range of 10 - 15 > > // Also need to tell some tools explicitly > > // about the number of 0s > > // I also added a little trickery to the test > > // which you will need to understand if you are > > // presenting this as homework ;) > > end > > else begin // just increment > > cnt <= cnt+1; > > end > > end > > endmodule > > > > > > I did a number of things, as you can see - now figure out why :) > > > > > > If you want a 50% duty cycle, it's a different matter. > > > > Cheers > > > > PeteS > > One fix in the test - more coffee!!!Article: 113579
Brian,
The specification is min 3pF; max 10 pF for 3E.
Austin
Brian Davis wrote:
> John Larkin wrote:
>
>>I might modestly suggest that my little circuit shifts the DC level
>>down, reduces the AC swing, terminates the differential trace
>>impedance, furnishes the pecl pulldown current, and presents the same
>>clean square wave to both fpga clocks, all independent of trace
>>lengths.
>>
>
> One caution, most Xilinx LVDS inputs have a Cin of around 8-12 pF
> (single ended), which will cause horrible {re}reflections when driven
> directly in a multidrop topology from a fast ECL driver- unless those
> MGT clock inputs have much better Cin than the regular LVDS inputs.
>
> Given the physical size of an FX60 package, there's likely to be
> enough distance between the two inputs to create a ledge or
> double clock with both inputs hanging off of the same net like that.
>
> The fanout buffer is probably the best solution, but if I had to make
> it work driving two 10 pF inputs with internal Rterm from a single net,
> I'd probably try series R's at each clock input to form a higher
> impedance line tap/divider coupling a portion of the signal off of an
> externally end-terminated net.
>
> other related FPGA LVDS notes:
>
> - Spartan 3E LVDS inputs have a much improved Cin of around 3 pF
>
> - Xilinx common mode input range with internal terminations:
> Although the LVDS inputs WITHOUT internal termination have
> a wide common mode range, the internally terminated variants
> (DIFF_TERM, DT) apparently are restricted to the much narrower
> common mode range of the associated differential OUTPUT standard
> to meet the specified internal termination tolerance
>
> - resistive ECL level shifts for solitary FPGA LVDS inputs:
> When driving a single LVDS input, I usually use something like
> Fig. 15 of AN1568, which creates the shift with a tapped pulldown:
> - http://www.onsemi.com/pub/Collateral/AN1568-D.PDF
>
> Plus additional provision for a series Rs from each junction,
> letting you tweak the back termination to match the line.
>
> Those resistors can then all be placed right at the driver,
> far, far away from the cluttered BGA breakout pattern, with
> the typical LVDS 100 ohm Rdiff at the receiver input.
>
> Brian
>
Article: 113580Here's my half-penny's worth: ######################## module div10(in,out); input in; output out; //put your ratio in here `define RATIO 10 // need 4 regs, because three will only give 8 states reg [3:0]Q; // at each rising edge of clock always @(posedge in) // if Q=9, next state is 0, else Q<=Q+1 Q<=(Q==`RATIO-1)?4'b0:Q+1; assign out=Q[3]; endmodule ######################## The above counts 0 1 2 ...7 8 9 Output is high 2 states in 10 -states 8 and 9 so not 1:1ratio If you want 1:1 ratio ######################## module div10(in,out); input in; output out; //put your ratio in here `define RATIO 10 // need 4 regs, because three will only give 8 states reg [3:0]Q; reg out; // at each rising edge of clock always @(posedge in) begin // if Q=9, next state is 0, else Q<=Q+1 Q<=(Q==`RATIO-1)?4'b0:Q+1; // output high for states 5 6 7 8 9 out<=(Q>4); end endmodule ######################## -- Per ardua ad nauseamArticle: 113581
Austin wrote: > > The specification is min 3pF; max 10 pF for 3E. > Try looking at the IBIS files, which show a total max Cin ( C_pkg plus C_comp ) of a mere 2.4 pF for a VQ100. Measured reflections off a fast LVDS driver in the lab also agree with a Cin value in that range. Perhaps I should file a WebCase asking Xilinx to update their datasheet to match their IBIS files :) Also, as I mentioned last April, detail for the different pin types is also missing from the datasheet: http://groups.google.com/group/comp.arch.fpga/msg/069c3ec4ec13de51 > > It's interesting to contrast the datasheet C values for the two >families: > >Cyclone-II > Cio 6 pF (typ) user I/O > Clvds 6 pF (typ) user I/O with LVDS > Cvref 21 pF (typ) user I/O with Vref function > Cclk 5 pF (typ) global clock input > >Spartan-3E > Cin 3 pF (min) 10 pF (max) > > Which makes no distinction between input only pins, I/O pins, >global clock input pins, left/right side clock pins, dual mode >config pins, Vref pins, dedicated config pins, etc > BrianArticle: 113582
Thanks for the responses. CVS has saved me a couple of times already, but I find it astonishing that this buggy garbage is out there. Regards MarcArticle: 113583
The problem that I had is mentioned in the answer ##22205 in the Answer Record Database. I did what the answer says and I solved my problem. Thanks for the answers anyway!Article: 113584
kyori wrote: > Hi, > > I am going to start a project of onboard high-speed CMOS image > processing. > I am goint to perform certain *block matching algorithm* or *Fourier > Transform* between successive frames and the fps would be 1000 or > more.. > > > The interface between the CMOS camera and the board is standord > CamLink. > I've learned that both DSP and FPGA based circuits can do certain > onboard image processing tasks, and I'd like to know whick is better? > DSP or FPGA? > > > I know some corporations use FPGA based boards as development boards > for their cameras. And my cooperators have some DSP development > experiences. So, the question arises, and I want your suggestions. I'd > like to know the advantages of each choise and maybe the direction of > onboard realtime high-speed image processing. > > > Thanks! > Any help would be appreciated. > Please go to wikipedia and look up "cross post". Compare what they have to say about cross posting with what they have to say about multiple posting. Then do it right. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 113585
What I want to avoid is the gray-to-binary conversion necessary to calculate population counts and flags afterwards. The design only introduces a simple handshake and replaces the gray resync registers by copy (hold) registers to create a safe false path for data between clock domains. IMO, this is simpler than having to decode gray counters before computing differences. Yes, that approach does sacrifice five extra FFs and some in-to-out latency for the handshaking in each direction (that could be reduced by using some async SR FFs) but it is a straight register-to-register design that enables direct pointer arithmetic on both sides. With gray counters, you end up needing a decoder for both local and remote counters on each side before doing arithmetic in each clock domain. As I said, designers are free to pick their poison. For most applications I have in mind (mostly DMA-like), I can afford to trade some latency and a few FFs for the ability to stick with a simple, plain binary register-to-register and decoder-less design. BTW, unless the gray decoders are fully absorbed by the arithmetic at no performance cost (doesn't gray code kill the carry chains?), my implementation should use fewer LUTs and be able to clock higher. Peter Alfke wrote: > Daniel, why do you want to avoid the Gray register? Your design is at > least as complicated and expensive, and incurs all this latency. Why do > it, when there are simpler ways to avoid it? > Peter Alfke > >> So, binary counters can be safely used by using frozen copies and >> handshaking. The caveat is higher latency than gray counters due to >> handshaking and register copies that add extra dependencies upon the >> other clock domain. >> >> As always, designers are free to pick their poison.Article: 113586
"tersono" <ethel.thefrog@ntlworld.com> wrote in message news:ff6bo29ov2ee3j9e30qkge4skuqt9hru9t@4ax.com... > > Here's my half-penny's worth: > > ######################## > module div10(in,out); > input in; > output out; > > //put your ratio in here > `define RATIO 10 > > // need 4 regs, because three will only give 8 states > reg [3:0]Q; > > // at each rising edge of clock > always @(posedge in) > > // if Q=9, next state is 0, else Q<=Q+1 > Q<=(Q==`RATIO-1)?4'b0:Q+1; > > assign out=Q[3]; > > endmodule > ######################## > > The above counts 0 1 2 ...7 8 9 > > Output is high 2 states in 10 -states 8 and 9 so not 1:1ratio > > If you want 1:1 ratio > > ######################## > module div10(in,out); > input in; > output out; > > //put your ratio in here > `define RATIO 10 > > // need 4 regs, because three will only give 8 states > reg [3:0]Q; > > reg out; > > // at each rising edge of clock > always @(posedge in) > > begin > // if Q=9, next state is 0, else Q<=Q+1 > Q<=(Q==`RATIO-1)?4'b0:Q+1; > > // output high for states 5 6 7 8 9 > out<=(Q>4); > end I don't like this notation, it forces me to delve deep into C-like syntax which focuses my mind away from hardware, but everyone and their own styles. > > endmodule > ######################## > -- > Per ardua ad nauseamArticle: 113587
Brian, I will look into that. From what I know about the design, the only way to reduce the C is to leave out the LVDS output driver (0.5pF less), or make the IO drive strength smaller. Until we drop the high output standards, the C is unlikely to get any smaller (just physics of a general purpose pin). It may be that 3E drops some of these (I will check). The Vref pins do not have any more load, until they are programmed to be a Vref, so we do not specify their C as a Vref (as the recommendation is to put a 0.1uF as close as possible to the Vref pin anyway). Sometimes a missing specification is just something not needed. But, if you filed it as a case, you should have received a reply as to why the specification did not require an update. Case #? Austin > Austin wrote: > >>The specification is min 3pF; max 10 pF for 3E. >> > > Try looking at the IBIS files, which show a total max Cin > ( C_pkg plus C_comp ) of a mere 2.4 pF for a VQ100. > > Measured reflections off a fast LVDS driver in the lab > also agree with a Cin value in that range. > > Perhaps I should file a WebCase asking Xilinx to update > their datasheet to match their IBIS files :) > > Also, as I mentioned last April, detail for the different > pin types is also missing from the datasheet: > > http://groups.google.com/group/comp.arch.fpga/msg/069c3ec4ec13de51 > >> It's interesting to contrast the datasheet C values for the two >>families: >> >>Cyclone-II >> Cio 6 pF (typ) user I/O >> Clvds 6 pF (typ) user I/O with LVDS >> Cvref 21 pF (typ) user I/O with Vref function >> Cclk 5 pF (typ) global clock input >> >>Spartan-3E >> Cin 3 pF (min) 10 pF (max) >> >> Which makes no distinction between input only pins, I/O pins, >>global clock input pins, left/right side clock pins, dual mode >>config pins, Vref pins, dedicated config pins, etc >> > > > Brian >Article: 113588
Austin wrote: > > From what I know about the design, the only way to reduce > the C is to leave out the LVDS output driver (0.5pF less), or > make the IO drive strength smaller. <snip> > It may be that 3E drops some of these (I will check). > The simplified S3E I/O drops DCI and some of the higher drive standards vs. S3, and adds DIFF_TERM support. > >> Which makes no distinction between input only pins, I/O pins, >> global clock input pins, left/right side clock pins, dual mode >> config pins, Vref pins, dedicated config pins, etc. > > The Vref pins do not have any more load, until they are programmed > to be a Vref, so we do not specify their C as a Vref <snip> > > Sometimes a missing specification is just something not needed. > Some inputs, such as global clocks or the MGT clock inputs of this thread, are likely to differ from general I/O, but are not documented as such in that single datasheet spec, nor in the IBIS files. > > > Perhaps I should file a WebCase asking Xilinx to update > > their datasheet to match their IBIS files :) > > But, if you filed it as a case, you should have received a reply as to > why the specification did not require an update. Case #? > If the "perhaps" and the smiley didn't give it away, that was intended as a humorous observation for those of us who have filed WebCases. BrianArticle: 113589
Brian Davis wrote: > > Austin wrote: > > > > From what I know about the design, the only way to reduce > > the C is to leave out the LVDS output driver (0.5pF less), or > > make the IO drive strength smaller. <snip> > > It may be that 3E drops some of these (I will check). > > > The simplified S3E I/O drops DCI and some of the higher > drive standards vs. S3, and adds DIFF_TERM support. > > > > >> Which makes no distinction between input only pins, I/O pins, > >> global clock input pins, left/right side clock pins, dual mode > >> config pins, Vref pins, dedicated config pins, etc. > > > > The Vref pins do not have any more load, until they are programmed > > to be a Vref, so we do not specify their C as a Vref <snip> > > > > Sometimes a missing specification is just something not needed. > > > Some inputs, such as global clocks or the MGT clock inputs of this > thread, are likely to differ from general I/O, but are not documented > as such in that single datasheet spec, nor in the IBIS files. > > > > > > Perhaps I should file a WebCase asking Xilinx to update > > > their datasheet to match their IBIS files :) > > > > But, if you filed it as a case, you should have received a reply as to > > why the specification did not require an update. Case #? > > > If the "perhaps" and the smiley didn't give it away, > that was intended as a humorous observation for those > of us who have filed WebCases. > > Brian Are you the Brian Davis that workled for Microdyne? -- Service to my country? Been there, Done that, and I've got my DD214 to prove it. Member of DAV #85. Michael A. Terrell Central FloridaArticle: 113590
Brian, That would make sense (dropping a low voltage strong standard reduces pin C). Dropping DCI would hardly save anything except area, however. I will take it that you did not file a webcase. With a webcase number, it could be tracked and solved, or escalated (and solved). Or even reported to myself or Peter (as some have done). Now that Spartan has "grown up", they are making their own decisions as to what to spend their silicon on, so I have lost track of some of their features. I should not have replied for them, as I really don't know what they are doing (without asking). Austin Brian Davis wrote: > Austin wrote: > >>From what I know about the design, the only way to reduce >>the C is to leave out the LVDS output driver (0.5pF less), or >>make the IO drive strength smaller. <snip> >>It may be that 3E drops some of these (I will check). >> > > The simplified S3E I/O drops DCI and some of the higher > drive standards vs. S3, and adds DIFF_TERM support. > > >>> Which makes no distinction between input only pins, I/O pins, >>>global clock input pins, left/right side clock pins, dual mode >>>config pins, Vref pins, dedicated config pins, etc. >> >>The Vref pins do not have any more load, until they are programmed >>to be a Vref, so we do not specify their C as a Vref <snip> >> >>Sometimes a missing specification is just something not needed. >> > > Some inputs, such as global clocks or the MGT clock inputs of this > thread, are likely to differ from general I/O, but are not documented > as such in that single datasheet spec, nor in the IBIS files. > > >>> Perhaps I should file a WebCase asking Xilinx to update >>>their datasheet to match their IBIS files :) >> >>But, if you filed it as a case, you should have received a reply as to >>why the specification did not require an update. Case #? >> > > If the "perhaps" and the smiley didn't give it away, > that was intended as a humorous observation for those > of us who have filed WebCases. > > Brian >Article: 113591
Maybe this is getting too long in the tooth. For B-to-G conversion use the D input of the binary counter, so it adds only one LUT delay, irrespective of length. There is no G-to-B conversion, because I derived the Gray code from the binary. Maybe this is getting too complex for just a short e-mail. My idea is: Do all the math in binary, convert to Gray in a synchronous transfer that does NOT add any latency, do the identity comparison between clock domains in Gray, then add some ciruitry to combat metastability. But, as I mentioned before, I never had the luxury of designing for a single-point solution. BTW, if you want to check existing patents, now you can use: www.google.com/patents. Very nice! Peter Alfke On Dec 17, 1:06 pm, "Daniel S." <digitalmastrmind_no_s...@hotmail.com> wrote: > What I want to avoid is the gray-to-binary conversion necessary to > calculate population counts and flags afterwards. > > The design only introduces a simple handshake and replaces the gray > resync registers by copy (hold) registers to create a safe false path > for data between clock domains. IMO, this is simpler than having to > decode gray counters before computing differences. > > Yes, that approach does sacrifice five extra FFs and some in-to-out > latency for the handshaking in each direction (that could be reduced by > using some async SR FFs) but it is a straight register-to-register > design that enables direct pointer arithmetic on both sides. With gray > counters, you end up needing a decoder for both local and remote > counters on each side before doing arithmetic in each clock domain. > > As I said, designers are free to pick their poison. > > For most applications I have in mind (mostly DMA-like), I can afford to > trade some latency and a few FFs for the ability to stick with a simple, > plain binary register-to-register and decoder-less design. > > BTW, unless the gray decoders are fully absorbed by the arithmetic at no > performance cost (doesn't gray code kill the carry chains?), my > implementation should use fewer LUTs and be able to clock higher. > > Peter Alfke wrote: > > Daniel, why do you want to avoid the Gray register? Your design is at > > least as complicated and expensive, and incurs all this latency. Why do > > it, when there are simpler ways to avoid it? > > Peter Alfke > > >> So, binary counters can be safely used by using frozen copies and > >> handshaking. The caveat is higher latency than gray counters due to > >> handshaking and register copies that add extra dependencies upon the > >> other clock domain. > > >> As always, designers are free to pick their poison.Article: 113592
Yes, one can do "ptrA == ptrB" directly in gray... but if I want to do "ptrA - ptrB" to know how much headroom I have, it does not work quite as nicely, this does require G2B conversion. For a gray implementation, it is probably preferable to generate a straight gray counter and convert that to linear binary for local use to avoid combinational paths and routing between the counter's registers and the other domain's resync registers since it increases the risk transcoding glitches (path delays + non-existing phase relation + ...) getting through. With a binary counter, the gray conversion must be registered on the local clock before resyncing to the other clock. In any case, the most important point of any design always is: it has to work. Peter Alfke wrote: > Maybe this is getting too long in the tooth. > For B-to-G conversion use the D input of the binary counter, so it adds > only one LUT delay, irrespective of length. > There is no G-to-B conversion, because I derived the Gray code from the > binary. > Maybe this is getting too complex for just a short e-mail. > My idea is: Do all the math in binary, convert to Gray in a synchronous > transfer that does NOT add any latency, do the identity comparison > between clock domains in Gray, then add some ciruitry to combat > metastability. > But, as I mentioned before, I never had the luxury of designing for a > single-point solution. > BTW, if you want to check existing patents, now you can use: > www.google.com/patents. Very nice! > Peter Alfke > > On Dec 17, 1:06 pm, "Daniel S." <digitalmastrmind_no_s...@hotmail.com> > wrote: >> What I want to avoid is the gray-to-binary conversion necessary to >> calculate population counts and flags afterwards. >> >> The design only introduces a simple handshake and replaces the gray >> resync registers by copy (hold) registers to create a safe false path >> for data between clock domains. IMO, this is simpler than having to >> decode gray counters before computing differences. >> >> Yes, that approach does sacrifice five extra FFs and some in-to-out >> latency for the handshaking in each direction (that could be reduced by >> using some async SR FFs) but it is a straight register-to-register >> design that enables direct pointer arithmetic on both sides. With gray >> counters, you end up needing a decoder for both local and remote >> counters on each side before doing arithmetic in each clock domain.Article: 113593
Marc Guardiani wrote: > Check to make sure that you have pullups on nCONFIG, CONFIG_DONE, and > nSTATUS. Passive serial configuration devices provide these pullups by > default, which could be missing on the board. Removing the configuration > device would remove the pullups, preventing configuration even from JTAG. Yes, there is (10k), which is why I'm scratching my head! :O Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 113594
I believe the original files were ASCII. The new binary .ise format is an "improvement". I think this was a huge mistake, the project file should be text - easily archived, documented, modified, etc. The binary file =is a nightmare for users. John Providenza David M. Palmer wrote: > In article <1166196746.946286.260300@n67g2000cwd.googlegroups.com>, > marc_ely <marc_ely@yahoo.co.uk> wrote: > > > The project file corruptions seem to occur randomly and will do various > > things, such as remove all files from the project (and not let you add > > them back), or not let you edit coregen parts, or a host of other > > things. > > > > Re-creating a project each time seems very laborious. Does anyone have > > any shortcuts to do this? Is there a TCL script that can be run? > > Archiving and Project Cleanup don't help. > > In general: > > a) Use a good version control system, such as CVS or SVN, and then > revert to a good version whenever you run into corruption > or > b) Save a copy of the project when it is working, and then copy it back > when things stop working. > > > a) is what you should do. b) is what you will do now that I've > suggested it. a) is what you will eventually do. > > > Why can't they just implement project files as text files and let you > > control them by hand? > > Because they haven't yet learned the lesson that ISE designers tend to > learn eventually. Text file project definitions always rise to the top > of the users' wish list eventually, even though it is initially easier > for the tool developers to just write() the binary structures into a > file. > > -- > David M. Palmer dmpalmer@email.com (formerly @clark.net, @ematic.com)Article: 113595
rponsard@gmail.com wrote: > I don't need your IP secrecies... > > This is for my students : what, in your current design, requires using > a fpga + softcore, in place of a COTS micro controler ? > less IC -> lower footprint, lower power cons., parallelism,... > > thanks, > raph > Fewer ICs? Yes - why have a $3 I2C PROM and a $5 microcontroller with the extra manufacturability programming bother when they can be emulated using a spare BRAM or two and 200 slices in a $40 FPGA that's already there for high-bandwidth signal processing? Lower power? Yes - sort of: more in the form of not needing an extra power regulator, clock source and other such items for the external microcontroller Parallelism? No - a soft core sounds like a pretty lousy choice for pure software parallelism... you might need to fill an XC5V330LX with microblazes to match modern CPUs. High-performance algorithms in FPGAs are much better served with pipelined parallelized logic implementations. Other reasons? - Cost: if the microcontroller core fits, it is practically free - Cost: an integrated microcontroler does not need IOs to interface with internal logic - Simplicity: an integrated microcontroller is easier to interface (no need to manage tristate IOs) - Simplicity: an integrated microcontroller can be customized - Simplicity: auxiliary microcontroller functions can be implemented in logic - Flexibility: all of the above - Flexibility: No compromising with multi-function pins - Performance, bandwidth, latency, etc. - If I had time, I could probably list over 100 reasons I have often been very frustrated with multi-function pins on off-the-shelf chips where two features I want often end up being mutually exclusive on most reasonably sized devices. With soft cores, nobody ever has to face this irritating limitation of hard-wired logic.Article: 113596
Let's leave it at that. We won't agree, but then: we do not have to... Peter Alfke BTW, Google lists over 1000 patents on FIFOs. A few of them are mine, but I could not believe the total number... On Dec 17, 6:02 pm, "Daniel S." <digitalmastrmind_no_s...@hotmail.com> wrote: > Yes, one can do "ptrA == ptrB" directly in gray... but if I want to do > "ptrA - ptrB" to know how much headroom I have, it does not work quite > as nicely, this does require G2B conversion. > > For a gray implementation, it is probably preferable to generate a > straight gray counter and convert that to linear binary for local use to > avoid combinational paths and routing between the counter's registers > and the other domain's resync registers since it increases the risk > transcoding glitches (path delays + non-existing phase relation + ...) > getting through. With a binary counter, the gray conversion must be > registered on the local clock before resyncing to the other clock. > > In any case, the most important point of any design always is: it has to > work. > > Peter Alfke wrote: > > Maybe this is getting too long in the tooth. > > For B-to-G conversion use the D input of the binary counter, so it adds > > only one LUT delay, irrespective of length. > > There is no G-to-B conversion, because I derived the Gray code from the > > binary. > > Maybe this is getting too complex for just a short e-mail. > > My idea is: Do all the math in binary, convert to Gray in a synchronous > > transfer that does NOT add any latency, do the identity comparison > > between clock domains in Gray, then add some ciruitry to combat > > metastability. > > But, as I mentioned before, I never had the luxury of designing for a > > single-point solution. > > BTW, if you want to check existing patents, now you can use: > >www.google.com/patents. Very nice! > > Peter Alfke > > > On Dec 17, 1:06 pm, "Daniel S." <digitalmastrmind_no_s...@hotmail.com> > > wrote: > >> What I want to avoid is the gray-to-binary conversion necessary to > >> calculate population counts and flags afterwards. > > >> The design only introduces a simple handshake and replaces the gray > >> resync registers by copy (hold) registers to create a safe false path > >> for data between clock domains. IMO, this is simpler than having to > >> decode gray counters before computing differences. > > >> Yes, that approach does sacrifice five extra FFs and some in-to-out > >> latency for the handshaking in each direction (that could be reduced by > >> using some async SR FFs) but it is a straight register-to-register > >> design that enables direct pointer arithmetic on both sides. With gray > >> counters, you end up needing a decoder for both local and remote > >> counters on each side before doing arithmetic in each clock domain.Article: 113597
222 wrote: >>> Correction, this is wrong >>> out =out +1; >>> Put this in instead >>> out =!out >>> >>> >> Since you toggle "out" every time your counter reaches 10, you are >> actually creating a waveform with twice the period you intended. Also, > > Does "always @(x)" work on _any_ change, i.e. it should react twice > on each clock, which would make it right, or does it default to positive > edge, > which would make it twice the period? As I said, I have only poked into verilog with a pole... I overlooked that little detail and yes, this does appear to be equivalent to clk'event in VHDL. In this case, try synthesizing your code with free tools from most FPGA vendors and I think you will get an error saying that you have to pick an edge - the FFs in all FPGAs I know of do not work with both edges, even the DDR IOBs are implemented with two register banks clocked on opposite edges. It might work the way you intended in simulation but I am almost 100% certain that it will fail in synthesis. >> because counting starts at 0 and you compare with 10, there are actually >> 11 counts between toggles instead of 10. > > Correct, I need to count to 9.Article: 113598
Hi, I start to work on FPGA Embedded system. I am trying to port the MonstaVista Linux on the system. First I built the system with EDK, the option for my system is: XUPV2P: powerPC 405 300MHz Bus 100MHz RS232_Uart_1 OPB UART 1655 (interrupt) Ethernet_MAC OPB ETHERNET (interrupt) SysACE_Compact Flash (interrupt) DDR_512MB I continue to work on software platform which is: Linux_mv131 version 1.01.b MEM_SIZE 0x10000000 PLB_CLOCK_FREQ_HZ 100000000 (100 MHz) Connected_periphs RS232_Uart_1, Ethernet_MAC, SysACE_CompactFlash, opb_intc_0 After generate the bitstream, then Generate Libraries and BSPs, I meet this error: TARGET_DIR : D:\My_Researches\Workspace\Report2\os\ ERROR:MDT - ERROR FROM TCL:- linux_mvl31 () - /usr/bin/bash: -c: line 1: unexpected EOF while looking for matching `"' /usr/bin/bash: -c: line 2: syntax error: unexpected end of file while executing "exec bash -c "cp -Rfp $cur_dir/linux/* $value"" (procedure "::sw_linux_mvl31_v1_01_b::post_generate" line 166) invoked from within "::sw_linux_mvl31_v1_01_b::post_generate 43482512" ERROR:MDT - Error while running "post_generate" for processor ppc405_0... make: *** [ppc405_0/lib/libxil.a] Error 2 If you meet this before, PLease give me some recommendation. I highly appreciate your help. Happy Christmas, Thang NguyenArticle: 113599
"johnp" <johnp3+nospam@probo.com> schrieb im Newsbeitrag news:1166412207.061866.73720@f1g2000cwa.googlegroups.com... >I believe the original files were ASCII. The new binary .ise format > is an "improvement". I think this was a huge mistake, the project > file should be text - easily archived, documented, modified, etc. The > binary file =is a nightmare for users. > > John Providenza > AGREE. nightmare, costs time(=money) for almost ever Xilinx PFGA user! most everyone agree. Still, Xilinx made the Choice to not use ascii project files :( possible some lousy programmer told they have too Antti
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