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
Totally_Lost wrote: > Austin Lesea wrote: > >>There is no such thing as "over-clocking" a FPGA: either it meets >>timing and works, or it doesn't. You may have to have very exotic >>cooling in order not to melt down the device, at speeds like 550 MHz >>with all of the logic toggling. The Industrial temp spec is the >>junction must be kept below 100C. Commercial grade must be kept below 85C. > > > Excuse me .... "Over clocking" is defined as clocking faster than MFG > Rated Specs. Certainly running any Xilinx FPGA past speced clock rates, > is clearly "over clocking". In Fact, Over clocking is by definition the > practice of taking parts (CPU, Memory, etc) to the edge of the process > where it fails, and backing it off so it doesn't. > > Who is lost? totally .... ???? > > >>You could increase the clock rate till the device fails to operate >>correctly, or can not be cooled, but in this application it would be >>very difficult to know if it wasn't operating correctly! Best to design >>it to work where it is supposed to work. > > > IFF, the spec's completely existed and were published openly. I can think of many lab situations where 'Over clocking' is both real, and desirable. If you want to do this in a FPGA, you should be able to, by design, include a deliberately-poor critical path, that can give information about the Vcc/Temp/MHz threshold. Scatter more than one, about the die, if you expect thremal skews. Then use this information to control your agressive cooling, ( water / freon pumps anyone? :) Clock speeds, and Vcc. This type of test can also be valid on a full production design, to verify you DO actually have a good margin on operation. I see a number of 'smarter' voltage regulators/controllers recently released, that are designed for exactly this type of verify-at-the-margins design. Of course, having this capability would let you see right thru the 'stamped speed grades', so I can understand FPGA vendors might want to claim there is no such thing :) -jgArticle: 107151
Hi all, I have two problem when reading the paper from [url]http://www.siliconlogic.com/pdf/Arbiters_MattWeber_SLE.pdf [/url] [1] Is Arbiter pure comb logic? If yes, shall its comb logic delay be constrained to within one clock cycle? [2] Shall one request and one grant both hold only one clock cycle? Best regards, DavyArticle: 107152
Thanks for the replies folks, I appreciate it. These are answers I suspected but wanted to hear from the horses mouth. I think the second paragraph of my post is the crux of what I was getting at and Jim's comments are particularly germane. Is the aspect of maintaining pinout compatability across a few device generations a poor business case as well ? It would appear to be so ... I understand the "Porsche" design philosophy and the apparant need to remain on the bleeding edge (with the silicon) in order to create and/or sustain a position of market leadership. It's one particular facet of a business model and, sometimes, it makes for wonderful magazine advertisements. For now, it seems that the company with the biggest baddest FPGA is a pre-requisite for making the most money. (Although placing and routing a fully loaded V4 LX200 on a Windows box is an exercise in extreme patience :) ) >From a financial perspective, Toyota is more successful company than Porsche. I realize that these automobile analogies can be taken far out of context. But there are times when I can't help but desire a little more "Toyota" and a little less "Porsche" from the big FPGA outfits. The rapid evolution of the silicon and underlying change in FPGA feature sets does impose challenges (i.e. consequences). The need to significantly re-work existing hardware that seeks a modest tech re-fresh is self evident .... and a rubbing point for ordinary average joe's like me. However, the stresses placed on the tool-chain developers cranking out ISE, EDK, SysGen, and related IP must be formidable. It probably also makes things interesting for the FAE staff and support services. The latest "gee-whiz" device will (and does) pre-empt soreley needed improvments to the design tools as well as refined integration and interplay between them. Integration that truly renders platform FPGA design fluid, user friendly, bug-free, and productive. I'm not saying that Xilinx hasn't made key strides in merging the EDK, ISE, DSP, and other flows. It is the basis for many shining moments in our shop. But, we've been users since day 1 and its got a long long way to go before my co-workers and I go through a day without muttering a four letter word :). Maybe all of this banter is/was simply about wondering where to put the eggs in the FPGA basket. Asking if there is possibly more money to be made by offering a "lesser device" or "more comprimised design approach" that, increases the investment in other areas to yield visibly superior tools, more FPGA IP, a quantum leap in productivity, ease of upgrading to future silicon devices etc. Regards, ChrisArticle: 107153
zcsizmadia@gmail.com wrote: > xilprg supports multiple Xilinx devices and supports Digilent USB and > Xilinx Parallel III cable. I would have thought it would have been less work to modify xc3sprog to support more devices and cables, it IS written in a very modular fashion. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8CArticle: 107154
Jim, what is this brouhaha about? Of course the chips are really faster than we guarantee. It would be terrible if it were the other way around. Yes, we guardband our speedsfiles. We do not want to get complaints from our tens (or hundreds) of thousands of customers. In a car you can exceed the turbo-boost level, in a tire you can exceed the max pressure, in any appliance you can exceed the line voltage, in food you can exceed the expiration data, etc. But don't then compain about food poisoning. It's hard to understand how grown-ups can indulge in this kind of silly argumentation... Peter Alfke =============================== Jim Granville wrote: > Totally_Lost wrote: > > Austin Lesea wrote: > > > >>There is no such thing as "over-clocking" a FPGA: either it meets > >>timing and works, or it doesn't. You may have to have very exotic > >>cooling in order not to melt down the device, at speeds like 550 MHz > >>with all of the logic toggling. The Industrial temp spec is the > >>junction must be kept below 100C. Commercial grade must be kept below 85C. > > > > > > Excuse me .... "Over clocking" is defined as clocking faster than MFG > > Rated Specs. Certainly running any Xilinx FPGA past speced clock rates, > > is clearly "over clocking". In Fact, Over clocking is by definition the > > practice of taking parts (CPU, Memory, etc) to the edge of the process > > where it fails, and backing it off so it doesn't. > > > > Who is lost? totally .... ???? > > > > > >>You could increase the clock rate till the device fails to operate > >>correctly, or can not be cooled, but in this application it would be > >>very difficult to know if it wasn't operating correctly! Best to design > >>it to work where it is supposed to work. > > > > > > IFF, the spec's completely existed and were published openly. > > I can think of many lab situations where 'Over clocking' is both > real, and desirable. > > If you want to do this in a FPGA, you should be able to, by design, > include a deliberately-poor critical path, that can give information > about the Vcc/Temp/MHz threshold. > Scatter more than one, about the die, if you expect thremal skews. > > Then use this information to control your agressive cooling, > ( water / freon pumps anyone? :) Clock speeds, and Vcc. > > This type of test can also be valid on a full production design, to > verify you DO actually have a good margin on operation. > > I see a number of 'smarter' voltage regulators/controllers recently > released, that are designed for exactly this type of > verify-at-the-margins design. > > Of course, having this capability would let you see right thru the > 'stamped speed grades', so I can understand FPGA vendors might want > to claim there is no such thing :) > > > -jgArticle: 107155
I inject a dll into the impact.exe, and hook DeviceIoControl and some other kernel32 APIs. impact.exe calls DeviceIoControl to read/write LPT I/O port using windriver6 driver. Instead of calling original windrvr DeviceIoControl function I just forward the TMS/TDI/TDO/TCK bits to Digilent USB (or any other programmer cable). On linux the easiest could be to create a brand new windrvr emulator driver where we implement all the IOCTLs used by impact. BTW, I have no clue why they are using the windriver as a device driver, because all the features they do with the Jungo driver ius really simple and generic(eg: user mode I/O access, USB acces to device, etc.) ZoltanArticle: 107156
Peter Alfke wrote: > Jim, what is this brouhaha about? > Of course the chips are really faster than we guarantee. It would be Certainly ... shouldn't be any other way. Simply if Austin wants to be insulting with "lost totally" comments, then that's the way he and Xilinx seem to be expecting to be treated as well when he is being clueless.Article: 107157
The Digilent USB driver was the biggest task in this project. The xc3sprog jtag interface doesn't really match the Digilent protocoll. So I had to create a little bit different JTAG engine than xc3sprog to support parport and USB, and to utilize the speed of Digilent USB device, and to have a reduced speed version. The other problem what I had was, to create a infrastructure to support multiple devices, where the algorithms may be similar, and to do that I should have rewritten the whole xc3sprog anyway. Zoltan Daniel O'Connor wrote: > zcsizmadia@gmail.com wrote: > > > xilprg supports multiple Xilinx devices and supports Digilent USB and > > Xilinx Parallel III cable. > > I would have thought it would have been less work to modify xc3sprog to > support more devices and cables, it IS written in a very modular fashion. > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8CArticle: 107158
Just because Austin (wrongly in my opinion) wrote: "There is no such thing as "over-clocking" a FPGA: either it meets timing and works, or it doesn't." is no reason to engage in this silly tirade. With the exception of (as usual) Ray Andrake, nobody posted here anything that had any redeeming value whatsoever. I think most of us have a better use of our time. Peter Alfke > Simply if Austin wants to be insulting with "lost totally" comments, > then that's the way he and Xilinx seem to be expecting to be treated as > well when he is being clueless.Article: 107159
Peter Alfke wrote: > It's hard to understand how grown-ups can indulge in this kind of silly > argumentation... > Peter Alfke For reference, a couple years back I had a couple XC2000E-8 parts in Xilinx BG560 proto boards running a hand packed bit serial RC5 cracking design at max clock rate ... petlier cooled, but could never get it power stable, even after augmenting the power bypass caps and buss wire to the socket. At first I blamed the sockets. Then put four of them on PCBs and tried again .... never could get it stable anywhere close to rated clock rate. A high count of LUT shift registers for the SBOX retiming chewed more power than the chip could easily handle as far as I can tell. Later another heat simulation modelling engine using LUT based shift register memory and bit serial math was unstable as well for VCCINT power reasons (no active IO) despite more than expected power decoupling, AND agressive cooling. AFAIK, both designs were well inside ISE reported timing margins, and valid designs from a tools perspective. Now maybe agressive use of bit serial LUT shift register memories will not send hand packed compute engines with large V4 and V5 parts over the edge, like the XCX2000E and XC2600E parts, but I'm pretty sceptical. Would love to get my hands on a Xilinx Board with XC4VLX200's on it, and give it a try. I'm not sure there is a valid cooling and power solution to reach that point for these packages. I'm pretty sure you agreed once these parts will not run an alternating 10101 pattern if fully loaded with LUT shift registers coupled out the DFF's. While not useful, that is a valid design ... and actually not that different that either of the applications that fell down using XCV2600E's. If you, Austin, and Xilinx say XCV2000E/XCV2600E parts fully hand packed with with bit serial compute engines should easily be stable with solid cooling, I for one, will remain skeptical. If you want to say the XC4VLX200's packed the same way can be made stable, or similar large XC5VLX parts, then I'll be happy to go back to the client with that guarentee if Xilinx will stand behind it 110%.Article: 107160
We have never claimed that perverse designs, deliberately created to exceed any normal Icc will work properly. A 100,000-bit shift register with alternating 1 and 0 is a perverse design. But read RayAndraka's posting. If anyone can pack FPGAs to the gills, while running a meaningful design, he can and does. And he gets paid for delivering real working products, not exercises that try to break the chip. Peter Alfke ============== Totally_Lost wrote: > Peter Alfke wrote: > > It's hard to understand how grown-ups can indulge in this kind of silly > > argumentation... > > Peter Alfke > > For reference, a couple years back I had a couple XC2000E-8 parts in > Xilinx BG560 proto boards running a hand packed bit serial RC5 cracking > design at max clock rate ... petlier cooled, but could never get it > power stable, even after augmenting the power bypass caps and buss wire > to the socket. At first I blamed the sockets. Then put four of them on > PCBs and tried again .... never could get it stable anywhere close to > rated clock rate. > > A high count of LUT shift registers for the SBOX retiming chewed more > power than the chip could easily handle as far as I can tell. > > Later another heat simulation modelling engine using LUT based shift > register memory and bit serial math was unstable as well for VCCINT > power reasons (no active IO) despite more than expected power > decoupling, AND agressive cooling. > > AFAIK, both designs were well inside ISE reported timing margins, and > valid designs from a tools perspective. > > Now maybe agressive use of bit serial LUT shift register memories will > not send hand packed compute engines with large V4 and V5 parts over > the edge, like the XCX2000E and XC2600E parts, but I'm pretty > sceptical. Would love to get my hands on a Xilinx Board with > XC4VLX200's on it, and give it a try. I'm not sure there is a valid > cooling and power solution to reach that point for these packages. I'm > pretty sure you agreed once these parts will not run an alternating > 10101 pattern if fully loaded with LUT shift registers coupled out the > DFF's. While not useful, that is a valid design ... and actually not > that different that either of the applications that fell down using > XCV2600E's. > > If you, Austin, and Xilinx say XCV2000E/XCV2600E parts fully hand > packed with with bit serial compute engines should easily be stable > with solid cooling, I for one, will remain skeptical. > > If you want to say the XC4VLX200's packed the same way can be made > stable, or similar large XC5VLX parts, then I'll be happy to go back to > the client with that guarentee if Xilinx will stand behind it 110%.Article: 107161
zcsizmadia@gmail.com wrote: > I've created a patch for Impact so it supoorts Digilent USB. This patch > could be modified to become some kind of SDK for different programmer > cable which are not supported by Impact. > > So here is my survey. What kind of programmer cables would you like to > use with Impact? > > Regards, > > Zoltan > Actually the question I have is what kinds of programmer cables can I use with linux. Impact -- I'd just as soon not use it. I prefer open source command line utilities. In fact I want everything to be a command line utility -- get rid of the IDE's. I use my own editor and "make" and I'm happy. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 107162
Peter Alfke wrote: > me_2003@walla.co.il wrote: > >>>the clock rate is not the issue beacuse I dont want to give two cycles >> >>for each write (not very elegant). > > > To hell with elegance. > Just make it work at the speed, and the cost, and the amount off effort > that is acceptable... > Peter Alfke > Gaaahhh. Always choose an elegant solution over the other kind. Part of elegance is that it includes those 3 things you require anyway, otherwise it wouldn't be elegant. Everyone's got a ton of stories about elegant solutions they've come up with. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 107163
Peter Alfke wrote: > We have never claimed that perverse designs, deliberately created to > exceed any normal Icc will work properly. A 100,000-bit shift register > with alternating 1 and 0 is a perverse design. Agreed ... but valid. On the other hand high density bit serial compute engines are not PERVERSE, but rather a clear valid production design ... if they would work. Their bit toggle rate isn't very far behind worst case of 10101. Now, Austin claims that valid designs will work at this density ... and these are valid designs. Am I totally lost, or is Austin blowing smoke and being purposefully insulting by claiming these designs will work if done by Ray at these densities? > But read RayAndraka's posting. If anyone can pack FPGAs to the gills, > while running a meaningful design, he can and does. > And he gets paid for delivering real working products, not exercises > that try to break the chip. > Peter Alfke A while back I had a nice long chat on the phone with Ray about this problem ... I don't think "ANYONE" ... even Ray, can make it work. Unless there is some God called "Anyone" that you are hiding in the wings. Now .... are you agreeing there are "valid" designs, real world production designs, of this class that you and Xilinx KNOW will not work? ..... ummm agreeing that my concerns after wasting nearly $6,000 in a board design are hard learned limitations of the Xilinx product? That Austin insultingly claims as false statements?Article: 107164
This is a meaningful exchange of ideas. But: We have a "Toyota", it's called Spartan. More seriously: Mask shrinks, or redesigns to a maller geometry would definitely make the chip smaller, probably cheaper, but would achieve only a tiny performance boost. The days are long gone when the next technology made the chip automatically much faster. If we can eke a 10% speed improvement out of the process alone, we are happy. The real speed boost of 30+% comes mainly from more creative designs and architectures, hard cores and better software. But not from smaller feature sizes and thinner gate oxide. (The trace-to-trace capacitance actually goes up with narrower traces packed more closely together). Higher performance requires radical innovation and real cleverness these days. Peter Alfke ================= tweed_deluxe wrote: > Thanks for the replies folks, I appreciate it. > > These are answers I suspected but wanted to hear from the horses mouth. > > I think the second paragraph of my post is the crux of what I was > getting at and Jim's comments are particularly germane. Is the aspect > of maintaining pinout compatability across a few device generations a > poor business case as well ? It would appear to be so ... > > I understand the "Porsche" design philosophy and the apparant need to > remain on the bleeding edge (with the silicon) in order to create > and/or sustain a position of market leadership. It's one particular > facet of a business model and, sometimes, it makes for wonderful > magazine advertisements. For now, it seems that the company with the > biggest baddest FPGA is a pre-requisite for making the most money. > (Although placing and routing a fully loaded V4 LX200 on a Windows box > is an exercise in extreme patience :) ) > > >From a financial perspective, Toyota is more successful company than > Porsche. I realize that these automobile analogies can be taken far > out of context. But there are times when I can't help but desire a > little more "Toyota" and a little less "Porsche" from the big FPGA > outfits. > > The rapid evolution of the silicon and underlying change in FPGA > feature sets does impose challenges (i.e. consequences). The need to > significantly re-work existing hardware that seeks a modest tech > re-fresh is self evident .... and a rubbing point for ordinary average > joe's like me. > > However, the stresses placed on the tool-chain developers cranking out > ISE, EDK, SysGen, and related IP must be formidable. It probably also > makes things interesting for the FAE staff and support services. The > latest "gee-whiz" device will (and does) pre-empt soreley needed > improvments to the design tools as well as refined integration and > interplay between them. Integration that truly renders platform FPGA > design fluid, user friendly, bug-free, and productive. I'm not saying > that Xilinx hasn't made key strides in merging the EDK, ISE, DSP, and > other flows. It is the basis for many shining moments in our shop. > But, we've been users since day 1 and its got a long long way to go > before my co-workers and I go through a day without muttering a four > letter word :). > > Maybe all of this banter is/was simply about wondering where to put the > eggs in the FPGA basket. Asking if there is possibly more money to be > made by offering a "lesser device" or "more comprimised design > approach" that, increases the investment in other areas to yield > visibly superior tools, more FPGA IP, a quantum leap in productivity, > ease of upgrading to future silicon devices etc. > > > Regards, > > > ChrisArticle: 107165
Peter Alfke wrote: > Jim, what is this brouhaha about? The OP, with what sounds very like a lab experiment, asked if FPGA could be overclocked. Austin replied with: >Austin Lesea wrote: >>There is no such thing as "over-clocking" a FPGA: either it meets >>timing and works, or it doesn't. So I (and others) pointed out, there IS such a thing as overclocking, and I gave some instances where one might consider doing that. > Of course the chips are really faster than we guarantee. It would be > terrible if it were the other way around. > Yes, we guardband our speedsfiles. We do not want to get complaints > from our tens (or hundreds) of thousands of customers. > In a car you can exceed the turbo-boost level, in a tire you can exceed > the max pressure, in any appliance you can exceed the line voltage, in > food you can exceed the expiration data, etc. > But don't then compain about food poisoning. I'm not sure the intention of the OP was to complain if it failed, his was the 'how fast can I do this' question. > It's hard to understand how grown-ups can indulge in this kind of silly > argumentation... I don't see much 'argumentation' - I think your comments agree with mine, that there IS a guardband (margin) in the design, and so you can overclock. ISTR you have mentioned "GHz-bench operation" frequency counters in FPGA ? Of course, overclocking is entirely in the 'customer care/no warranties' pigenhole, but I think Austin needs a little care with his sweeping statements. -jgArticle: 107166
Andy wrote: [...] > To illustrate, by modifying the original example: > > my_state_proc: process(clk, reset_n) > type my_state_type is (wait, act, test); > variable my_state: my_state_type; > begin > if (reset_n = '0') then > my_state := wait; > my_output <= '0'; > elsif (rising_edge(clk)) > case my_state is > when wait => > if (some_input = some_value) then > my_state := act; > end if; > ... > ... > when act => > if some_input = some_other_val then > my_output <= yet_another_value; > else > ... > end if; ... > when test => > ... > when others => > my_state := wait; > end case; > end if; > end process; > > The only time I would use separate logic code for outputs is if I > wanted to have combinatorial outputs (from registered variables, not > from inputs). Then I would put the output logic code after the clocked > clause, inside the process. I try to avoid combinatorial > input-to-output paths if at all possible. > [...] Thanks for this example. I have been always trying to avoid variables for things like this and it's interesting to see them used correctly. The problem I see with the approach comes in complicated code where several signals depend on my_state (say 3-4 is enough). Then, the single-process-handling-everything becomes rather convoluted. Besides, since my_state is a variable local to the process, you can't see it outside so you can't use it to drive other signals. So basically you force all code dealing with my_state to be in one process. Another thing is that I prefer out-of-process statements for combinatorial logic, because IMHO it makes a cleaner separation (I immediately see it's combinatorial, without the need to see if it has some extra "end if"s below it that signify it's clocked. comb_out <= '1' when my_state = act else '0'; Somehow I immediately see the combinatorial logic here (if it gets too hairy a function can be coded). EliArticle: 107167
kayrock66@yahoo.com wrote: > I wouldn't bother, the abstraction added is not sufficient above > properly written HDL to warrent the extra step. To get reasonable > implimentation you will end up writting "C" in such a limited form it > won't help you much. Certainly not for several reasons. First, the coding in VHDL/VERILOG can be MUCH MUCH of a worse style, especially building FSM's awkwardly in VHDL/Verilog that are a natural nesting of If-then-else wrapped in natural for/while/do loops. Secondly, process style coding in VHDL isn't that different then C to start with, and lacks the horrible VHDL verbosity and constructions. Third, I'd like to see what applications you think this is true for ... it may well mean you need to think in other ways. Give some examples. BTW ... see the examples in the FpgaC projects current SVN directory. I will be adding several more, as well as completing the PCI core project once some limitations of the Beta-2 release are fixed shortly. I'm currently coding a symbolic boolean solver to replace the truth table form we got from the TMCC project that will do a much better job of technology mappling and allow better time/space tradeoffs for combinatorials. Some of the examples I will be rewritting in a more natural form soon, taking advantage of soon to be release features in Beta-3 and Beta-4 this fall. I agree some of the examples are just as twisted as VHDL/Verilog designs, just to make sure what is instantiated is a pipelined high performance bit stream. Many of these tricks can be equally well used in Handel-C or Streams-C, and not that unlike the VHDL/Verilog constructs to do the same thing. After having read several PCI core implementations in VHDL and Verilog, I can clearly say they are MUCH MUCH harder to understand, and not nearly as clear and concise as the C version prototype I currently have as a work in progress example.Article: 107168
> In my original post I had no intention to reach a common consensus. I
> wanted to see practical code examples which demonstrate the various
> techniques and discuss their relative merits and disadvantages.
>
> Kind regards,
> Eli
Hi Eli,
Ok, that's something different.
Earns some contribution from my side :-)
My example uses 3 Processes.
The first one is the simple state Register.
the second is the combinatocrical branch selection,
The third creates the registered outputs.
Recognize that the third process uses NextState for the case selection.
Advantage: Outputs change exactly at the same time as the states do.
Disadvantage: The branch logic is connected to the output logic, causing
longer delays.
Workaround: If a one clock delay of the outputs doesn't matter, Current
State can be used instead.
The only critical part I see is the second process. Because it's
combinatorical some synthesis tools might generate latches here, when
the designer writes no proper code. But we all should know how to write
latch free code, don't we? ;-)
The structure is very regular, which makes it a useful template for
autogenerated code.
Have a nice synthesis
Eilert
ENTITY Example_Regout_FSM IS
PORT (Clock : IN STD_LOGIC;
Reset : IN STD_LOGIC;
A : IN STD_LOGIC;
B : IN STD_LOGIC;
Y : OUT STD_LOGIC;
Z : OUT STD_LOGIC);
END Example_Regout_FSM;
ARCHITECTURE RTL_3_Process_Model_undelayed OF Example_Regout_FSM IS
TYPE State_type IS (Start, Middle, Stop);
SIGNAL CurrentState : State_Type;
SIGNAL NextState : State_Type;
BEGIN
FSM_sync : PROCESS(Clock, Reset)
BEGIN -- CurrentState register
IF Reset = 1 THEN
CurrentState <= Start;
ELSIF ClockEVENT AND Clock = 1 THEN
CurrentState <= NextState;
END IF;
END PROCESS FSM_sync;
FSM_comb : PROCESS(A, B, CurrentState)
BEGIN -- CurrentState Logic
CASE CurrentState IS
WHEN Start =>
IF (A NOR B) = 1 THEN
NextState <= Middle;
END IF;
WHEN Middle =>
IF (A AND B) = 1 THEN
NextState <= Stop;
END IF;
WHEN Stop =>
IF (A XOR B) = 1 THEN
NextState <= Start;
END IF;
WHEN OTHERS => NextState <= Start;
END CASE;
END PROCESS FSM_comb;
FSM_regout : PROCESS(Clock, Reset)
BEGIN -- Output Logic
IF Reset = 1 THEN
Y <= 0;
Z <= 0;
ELSIF ClockEVENT AND Clock = 1 THEN
Y <= 0; -- Default Value assignments
Z <= 0;
CASE NextState IS
WHEN Start => NULL;
WHEN Middle => Y <= 1;
Z <= 1;
WHEN Stop => Z <= 1;
WHEN OTHERS => NULL;
END CASE;
END IF;
END PROCESS FSM_regout;
END RTL_3_Process_Model_undelayed;
Article: 107169Antti wrote: > no C is not answer. > sure some C to FPGA tools work pretty nicely. > > I think the ability to use any HDL if required is a bit + > quite often some imported IP is in the "other HDL" > so you cant do it all in single language. and always > rewriting from one into another isnt also an option. I'm always open to practical examples where someone thinks VHDL or Verilog is clearly the ONLY solution, or even the best solution. First I'd like a chance to consider what is wrong with FpgaC today, and what might be done better in future releases as it matures. As FpgaC matures over the next year it would be very nice to get rid of the bad warts. At the same time, I believe that many applications are justified applications of Handel-C, StreamsC, SystemC, or even FpgaC as it matures. Writing VHDL/Verilog largely has all the same complexity and long term maintainence problems that writting structure assembly language has for the software world. Likewise, moving up the ladder to HLL's like C which have good hardware targeting will bring hardware design up a notch in reliability and long term maintainability that the software world saw in abandoning assembly language, and even C level coding today. Allowing hardware designers to design at TTL building block level creates unnecessary complexity in the design expression that is prone to costsly error introduction, if not for the original designer, certainly for less skilled engineers that are required to support the design for the product life. Unfortunely, hardware engineers frequently build unnecessary design complexity into a project, by having "fun" doing binary design level implementations, rather than abstract process level data flow and FSM construction using higher level language abstractions that are easier to design with, less error prone, and much more supportable by a larger class of engineers. There is a reason the software world doesn't allow software engineers to write production programs in native machine language ones and zeros, or even use high level assembly languange in most cases .... and increasingly not even low level C code. The time for allowing engineers to design hardware at the ones and zeros binary level is passing too as the tools like System C emerge and produce reasonable synthesis with co-design.Article: 107170
zcsizmadia@gmail.com schrieb: > I've created a patch for Impact so it supoorts Digilent USB. This patch > could be modified to become some kind of SDK for different programmer > cable which are not supported by Impact. > > So here is my survey. What kind of programmer cables would you like to > use with Impact? > > Regards, > > Zoltan Zoltan, here is the survey ==> and and all. if you do want todo some work on the topic, it makes WAY more sense to "discover" the Impact CableServer protocol, in that way you dont need to patch anything, you can support both win and linux and you can be either adding 3rdr party programmer support to impact by using 3rd party "cableserver" or you can add support for impact supported cables to 3rd party hardware. the protocol is easy to figure out, start cableserver with debug logging, then etherreal and run impact and make some notices, then start your own cableserver and monitor difference in the comms. I have done preliminary work for this, but unfortunatly I have not enought time right now for this task.If you are interested I can give all the info and programs I have (partial cableserver emu). If you need some Xilinx board I could have some overleft to 'sponsor' the project. Antti XSIM => MicroBlaze+uClinux Simulator (open plugin SDK) http://xilant.comArticle: 107171
GaLaKtIkUs=99 schrieb: > Antti wrote: > > GaLaKtIkUs=99 schrieb: > > > > > In the Virtex-4 user guide (ug070.pdf p.365 table 8-4) it is clearly > > > indicated that for INTERFACE_TYPE=3DNETWOKING and DATA_RATE=3DSDR the > > > latency should be 2 CLKDIV clock periods. > > > I instantiated an ISERDES of DATA_WIDTH=3D6 but I see that valid outp= ut > > > appears on the next CLKDIV rizing edge. > > > Any explanations? > > > > > > Merci d'avance! > > > > advice: dont belive the simulator, its not always correct. > > place the iserdes and chipscope ILA into dummy toplevel, load some FPGA > > and look what happens in real silicon. > > > > Antti > > The only Virtex-4 based board I have is the ML403. Any advice on which > I/O to use? > Is it possible to use some signal on one the expansion headers? i.e to > loop it back without load resistor? or I should use DCI? gosh, just use any IO if some pins are accessible put a jumper on them for loopback, or use same io pin for in and out AnttiArticle: 107172
Peter Alfke wrote: > Higher performance requires radical innovation and real cleverness > these days. > Peter Alfke Managing product costs do as well. Heavy re-engineering costs, new regulatory certifications, multiply stocked SKUs for warranty replacement, cross version updates because of component changes, and a miriad of like problems make product life management a nightmare in the fast moving FPGA world. Just parts cost reduction, combined with fewer product rev costs, makes a whole lot of sense ... and the basic thrust of the OP's arguments. To sell Xilinx parts to and end user market, it's not just mask costs that affect volume. The ripple changes down the customer chains are many more real dollars than high mask costs .... just in regulatory recertification, build and life management costs.Article: 107173
Antti wrote: > GaLaKtIkUs=99 schrieb: > > > Antti wrote: > > > GaLaKtIkUs=99 schrieb: > > > > > > > In the Virtex-4 user guide (ug070.pdf p.365 table 8-4) it is clearly > > > > indicated that for INTERFACE_TYPE=3DNETWOKING and DATA_RATE=3DSDR t= he > > > > latency should be 2 CLKDIV clock periods. > > > > I instantiated an ISERDES of DATA_WIDTH=3D6 but I see that valid ou= tput > > > > appears on the next CLKDIV rizing edge. > > > > Any explanations? > > > > > > > > Merci d'avance! > > > > > > advice: dont belive the simulator, its not always correct. > > > place the iserdes and chipscope ILA into dummy toplevel, load some FP= GA > > > and look what happens in real silicon. > > > > > > Antti > > > > The only Virtex-4 based board I have is the ML403. Any advice on which > > I/O to use? > > Is it possible to use some signal on one the expansion headers? i.e to > > loop it back without load resistor? or I should use DCI? > > gosh, just use any IO if some pins are accessible put a jumper on them > for > loopback, or use same io pin for in and out > > Antti I use the ZBT_SRAM_clk and clk_feedback present on the board. Thanks you for help. A small question: what does mean gosh? A+Article: 107174
GaLaKtIkUs=99 schrieb: > Antti wrote: > > GaLaKtIkUs=99 schrieb: > > > > > Antti wrote: > > > > GaLaKtIkUs=99 schrieb: > > > > > > > > > In the Virtex-4 user guide (ug070.pdf p.365 table 8-4) it is clea= rly > > > > > indicated that for INTERFACE_TYPE=3DNETWOKING and DATA_RATE=3DSDR= the > > > > > latency should be 2 CLKDIV clock periods. > > > > > I instantiated an ISERDES of DATA_WIDTH=3D6 but I see that valid = output > > > > > appears on the next CLKDIV rizing edge. > > > > > Any explanations? > > > > > > > > > > Merci d'avance! > > > > > > > > advice: dont belive the simulator, its not always correct. > > > > place the iserdes and chipscope ILA into dummy toplevel, load some = FPGA > > > > and look what happens in real silicon. > > > > > > > > Antti > > > > > > The only Virtex-4 based board I have is the ML403. Any advice on which > > > I/O to use? > > > Is it possible to use some signal on one the expansion headers? i.e to > > > loop it back without load resistor? or I should use DCI? > > > > gosh, just use any IO if some pins are accessible put a jumper on them > > for > > loopback, or use same io pin for in and out > > > > Antti > > I use the ZBT_SRAM_clk and clk_feedback present on the board. > Thanks you for help. > > A small question: what does mean gosh? > > A+ gosh no idea! maybe is another perfectly perfect word, like "spunk" invented by Pippi 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