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
> Notice that it is important to register the read address. This is
> required to infer block ram. If you don't do that, you will get LUT ram.
Hm so in other words, my block RAM wont be infered correctly because I
made the process sensitive to the readaddress as below?
architecture Behavior of ram_data is
type ram_type is array (0 to SIZE-1) of std_logic_vector (31 downto 0);
signal ram : ram_type :=
( X"00000063",
X"0000007c",
....
);
begin
PROC_ram : process (clk, rw_addr_cp0)
begin
if (rst = '0') then -- optional reset
data_out_cp0 <= (others => '0');
elsif (clk'event and clk = '1') then
-- memory write:
if (ew_cp0 = '1') then
if (unsigned(rw_addr_cp0) >= 0 and unsigned(rw_addr_cp0) <=
SIZE-1) then
ram(conv_integer(unsigned(rw_addr_cp0))) <= data_in_cp0;
end if;
end if;
end if;
-- memory read:
if (unsigned(rw_addr_cp0) >= 0 and unsigned(rw_addr_cp0) <=
SIZE-1) then
data_out_cp0 <= ram(conv_integer(unsigned(rw_addr_cp0)));
end if;
end process PROC_ram;
end Behavior;
Article: 126201On 16 nov, 05:15, "Toni Merwec" <mistertorp...@freenet.de> wrote: > > I don't think that a regular low-jitter clock device (and it HAS to be > low-jitter as for the reference for the MGTs) can drive 6 inputs over > several centimeters. I already used the ICS843020 clock synthesizer in > several other projects and wanted to use it again. Reason for the ICS is > that it features a programmable output frequency in the range of 35 - 700 > MHz. Problem is, the ICS843020 has only two outputs. The Epson EG2121CA > device that is proposed in the Virtex-4 MGT user guide is not suitable > because these devices are restricted to one fixed frequency. Check out ICS843001-21: http://www.xilinx.com/products/boards/ml505/datasheets/ics843001-21.pdf It's a frequency synthesizer with very low jitter. It's used on Xilinx ML505 board for RocketIOs. Then I'm pretty sure that you can find a low skew clock buffer to drive your 6 clocks. PatrickArticle: 126202
Andrew Ganger wrote: >> Notice that it is important to register the read address. This is >> required to infer block ram. If you don't do that, you will get LUT ram. > > Hm so in other words, my block RAM wont be infered correctly because I > made the process sensitive to the readaddress as below? > That's right, unless rw_addr_cp0 is registered somewhere else. And even then, different versions of ISE can be somewhat finicky about exactly how the code is written. Other synthesis tools may have their own requirements, but a registered read address is universal. I consider it clearest to keep the register at the place where I am inferring the BRAM.Article: 126203
On Nov 16, 12:01 pm, Ben Jackson <b...@ben.com> wrote: > On 2007-11-16, Jimb...@gmail.com <Jimb...@gmail.com> wrote: > > > > >> You probably forgot to set C_TEMAC_INST in the second PLB temac (in > >> addition to C_TEMAC_BOTH_USED). > > > I guess the question now is, how can i override this value manually > > and prevent the tools from doing this? > > Edit the MHS file in a text editor. > > -- > Ben Jackson AD7GD > <b...@ben.com>http://www.ben.com/ Yeah, I actually tried that this morning. Here's my updated MHS file: BEGIN plb_temac PARAMETER INSTANCE = plb_temac_1 PARAMETER HW_VER = 3.00.a PARAMETER C_TEMAC_BOTH_USED = 1 # User Added parameter JPM 7/16/07 PARAMETER C_TEMAC_INST = 1 # # END USER ADDED parameter PARAMETER C_PLB_CLK_PERIOD_PS = 10000 After re-running all I didnt see the message in platgen.log but still saw the same message in system.log and libgen.log. It seems something is overriding my parameter assignment.Article: 126204
u_stadler@yahoo.de wrote:
> but whatever i do to the ports of the memory they always stay 'x'.
> shouldn't at least the input port be '0' or '1' if i apply that
> signal?
Only if the testbench first does a write cycle
and then a read from the same address.
Otherwise x is probably the right answer.
-- Mike Treseler
Article: 126205On Nov 16, 12:50 pm, Mike Treseler <mike_trese...@comcast.net> wrote: > u_stad...@yahoo.de wrote: > > but whatever i do to the ports of the memory they always stay 'x'. > > shouldn't at least the input port be '0' or '1' if i apply that > > signal? > > Only if the testbench first does a write cycle > and then a read from the same address. > Otherwise x is probably the right answer. > > -- Mike Treseler Xilinx BlockRAMs must have a clock to perform any operation, even a read. This is not intuitively obvious, but it is an absolute requirement. Peter Alfke, XilinxArticle: 126206
On Nov 16, 2:07 pm, Ray Andraka <r...@andraka.com> wrote: > Andy wrote: > > > I'm old enough have done a lot of ABEL/CUPL for PALs, and schematic > > capture for xc2000/xc3000 designs, and I hated VHDL for a long time. > > My old boss hung up a quote of mine about trying to design SW by > > drawing pictures, while HW design was hell-bent-for-leather, headed > > the other way. Previous poster notwithstanding, I used GED (precursor > > to Concept) to build wonderful, intelligently parameterizable > > functional blocks that could be interconnected in an easily > > understood, structual way. Unless I needed to design a state > > machine... That's when I started to design behaviorally, instead of > > structurally. Now, design structure is mostly about managing > > behavioral complexity, and a only little about managing physical > > complexity. Once you make that thought shift, it's gravy from there > > on. > > Andy, before I abandoned schematics, I had come up with a very workable > graphical state machine entry for schematics. The schematic looked just > like a state diagram. Basically, I made schematic wrappers that looked > like state diagram elements so that putting together the state machine > was much like drawing it out. Of course it resulted in a decoded state > machine, but that was OK since that was the style that generally yielded > the best results in FPGAs of the time anyway. The components were: a > state bubble containing a flip-flop; a decision box, which contained a > pair of AND gates with the decision input inverted into on and not into > the other; and a wire junction, which wrapped around an OR gate. I > think there were a few other elements, but these were the major ones. > It made for very fast entry, and very readable state machine schematics. > I also had a methodology for encoded state machines that made it easy > to read the function. I don't recall off the top of my head what I did > there, but it basically involved a mux element with all the states shown. I remember hearing the rumor that the Graychip (now TI) GC4014 quad DDC chips were designed using schematic entry - quite a feat considering the complexity of the chips. I'm sure the design involved a library like the one Ray described, eventually building NCO's and complex multipliers out of gates. Granted, that was an ASIC design, and maybe it makes more sense there, but still... maybe DSP folks are more biased to this design methodology than pure digital folks?Article: 126207
All, That would make no sense at all (to have a TI DSP soft core) in an FPGA! It is far less expensive to just buy the part from TI. As for making TI 'uncomfortable', we consider TI a great partner: they sell their DSPs into many markets, and when they can't do something fast enough, they sell their DSPs and our FPGAs. If we sell our FPGA into a market, and there is a TI DSP that can do a job where we are not competitive, we encourage the customer to use TI, too. Are there some jobs that TI wins, or we win exclusively (the other is just not needed)? Sure. That happens if we were partners, or not. We sell, they sell. It is not a "zero-sum" game where there can only be one winner every time: we are all winning (customer, Xilinx, TI)! Customer knows that Xilinx and TI are working together to provide them with the best solution to their problems. AustinArticle: 126208
On Fri, 16 Nov 2007 13:48:11 -0800 (PST), Dave <dhschetz@gmail.com> wrote: >I remember hearing the rumor that the Graychip (now TI) GC4014 quad >DDC chips were designed using schematic entry - quite a feat >considering the complexity of the chips. I'm sure the design involved >a library like the one Ray described, eventually building NCO's and >complex multipliers out of gates. Granted, that was an ASIC design, >and maybe it makes more sense there, but still... maybe DSP folks are >more biased to this design methodology than pure digital folks? When designing control logic, I generally very much prefer to write - and think - in HDL because it helps me describe sequential flow of behaviour. When designing datapath, and especially when describing fixed-function (or nearly fixed-function) DSP datapath, I still tend to use HDLs nowadays but there's no doubt I'm thinking in block-level schematic - adders, normalisers, MACs, that sort of thing. Note that users of DSP simulation software generally use block diagrams rather than procedural code, so I reckon I'm in good company. I guess the deal is roughly this: When you have concurrently executing blocks each of whose functions is nontrivial but largely invariant (same behaviour on every clock tick), it's easier to think in block diagram terms. When you have a complicated function whose behaviour varies rapidly over time (state machine), it's easier to think in terms of procedural code (at least, it is for me). Ray Andraka's ingenious state-diagram-to-schematic transformation, which I think he's described here in the past, is a good example of an alternative view. *All* our design-capture tools and methodologies are nothing more than steps on the way from design concept to implementation. If a tool, language, or diagram-methodology is to be useful, it must: - provide a convenient bridge between two points on the design refinement pathway that otherwise would be too far apart to link in a single step; - provide a framework for thinking that is not too restrictive, but also is prescriptive enough to allow you to get started on a problem easily; - be rigorous enough to allow you, and (ideally) automated tools, to reason about the design; - be readily comprehensible by other practitioners. Schematics, state diagrams, Boolean equations, HDLs and graphical DSP design tools have all proved their worth against these criteria. Changes in technology, and changes in the scope and difficulty of designs that you undertake, will shift the balance in favour of some and against others. It's silly to be dismissive of any of them out of context. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 126209
I've just heard from Xilinx support that the second MAC does not work with ISE/EDK 9.1. The solution is to upgrade to 9.2. Ben, thanks again for your help.Article: 126210
On 16 Nov., 22:47, Peter Alfke <pe...@xilinx.com> wrote: > On Nov 16, 12:50 pm, Mike Treseler <mike_trese...@comcast.net> wrote:> u_stad...@yahoo.de wrote: > > > but whatever i do to the ports of the memory they always stay 'x'. > > > shouldn't at least the input port be '0' or '1' if i apply that > > > signal? > > > Only if the testbench first does a write cycle > > and then a read from the same address. > > Otherwise x is probably the right answer. > > > -- Mike Treseler > > Xilinx BlockRAMs must have a clock to perform any operation, even a > read. This is not intuitively obvious, but it is an absolute > requirement. > Peter Alfke, Xilinx well i used a clock of course.. urbanArticle: 126211
Herbert Kleebauer <klee@unibwm.de> wrote: >A few month ago I asked for a recommendation for FPGA (not a ready to use demo board) >which could be handled with simple home equipment. I got the link to: > >http://www.enterpoint.co.uk/moelbryn/darnaw1.html > >We ordered a few samples and did some experimenting. Here the documentation >for a simple 16 bit CPU implemented on the DARNAW1. It includes also a step by >step introduction which should allow anybody still unfamiliar with FPGA design >to implement the demo in less than a hour. > >ftp://137.193.64.130/pub/mproz/mproz3_e.pdf (documentation) >ftp://137.193.64.130/pub/mproz/mproz3.zip (documentation + schematics) > >Conclusion: >The board is great, not just an other demo board, but rather a package >converter from the FPG ball grid to a pin grid array with the necessary >voltage converters and program flash on board. Sadly the same can't be >said about the current Xilinx software (schematic editor + simulator), >so we will try to stay as long as possible with the X3000 chips and the >old Xilinx DOS software (with ViewLogic schematic entry + simulator). At this moment I think either Verilog or VHDL is the best route. And it probably is for the next few years. I have a customer which has a lot of legacy in schematics (Orcad/ XNF format) which is totally useless with the newer ISE versions. Their VHDL code however ports nicely between various ISE versions. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 126212
Dave wrote: > I remember hearing the rumor that the Graychip (now TI) GC4014 quad > DDC chips were designed using schematic entry - quite a feat > considering the complexity of the chips. I'm sure the design involved > a library like the one Ray described, eventually building NCO's and > complex multipliers out of gates. Granted, that was an ASIC design, > and maybe it makes more sense there, but still... maybe DSP folks are > more biased to this design methodology than pure digital folks? I can tell you for fact that I designed systems considerably more complex than those DDC chips using schematics. In fact many of those systems included DDCs that compared very favorably against the Graychip devices in terms of performance. For example, the design described in my paper "An FPGA based processor yields a real time high fidelity radar environment simulator" (http://www.andraka.com/files/mapld.pdf) was a design done with schematics that involved more than a dozen unique XC4025 designs. It would have been impossible to meet the density and performance requirements with the VHDL tools available at the time because of the floorplanning required to get it all to fit.Article: 126213
I am looking at a low end Dell laptop, the Vostro 1500, as a new computer for work. I may supplement this later with a new desktop unit for crunching FPGA designs, but I will also be using this laptop for this sort of work. I am looking for advice on the differences in CPUs for FPGA work and anything else that is relevant. I know that parallel ports are going the way of the serial port and the dodo bird, but I can live with that. Most tools are available as USB devices now. This particular computer comes with WindowsXP rather than Vista. From what I have heard, that is an advantage. But I notice that the internal bluetooth adapter is specific for XP and others from Dell are specific for Vista. Any idea what is up with that? Is there any significant advantage to using XP pro over XP home? This machine also has the "Intel(R) Integrated Graphics Media Accelerator X3100". Is that just another way of saying "integrated video"? Several of my other machines have had integrated video and it does seem to drag down the CPU noticeably. Any idea if I will notice the drag on the Core 2 Duo? They also offer an Nvidia Gforce 8400 GS adapter for $100 and an 8600 for $200 more. Any idea if these are worth it? The 1500 says it has "VGA video output & S-Video". Does that mean I can connect two monitors for dual display? The CPU is a T5270 (1.4 GHz, 2 MB cache) with upgrades to various processors for significant money. The first stepup is to a T5470 (1.6 GHz) for $75 and others range up to $575! I am thinking I can live with the slower processor. The memory is 2GB. I was looking at the Vostro 1000 earlier this week with an AMD TK-53 processor (1.5 GHz, 512 KB cache) and a smaller hard drive. It was $50 more so the 1500 looks like the better deal. Are there any significant differences in the two CPUs for FPGA work? I guess the small cache of the TK-53 would make it significantly slower for FPGA work. I saw a thread from earlier this year discussing some of this. I wonder how much laptops have improved since then.Article: 126214
On Nov 17, 1:22 am, rickman <gnu...@gmail.com> wrote: > I am looking at a low end Dell laptop, the Vostro 1500, as a new > computer for work. I may supplement this later with a new desktop > unit for crunching FPGA designs, but I will also be using this laptop > for this sort of work. I am looking for advice on the differences in > CPUs for FPGA work and anything else that is relevant. > > I know that parallel ports are going the way of the serial port and > the dodo bird, but I can live with that. Most tools are available as > USB devices now. > > This particular computer comes with WindowsXP rather than Vista. From > what I have heard, that is an advantage. But I notice that the > internal bluetooth adapter is specific for XP and others from Dell are > specific for Vista. Any idea what is up with that? Is there any > significant advantage to using XP pro over XP home? > I prefer xp-pro because it allows you to use it over remote desktop. As to whether that feature is needed on a laptop is your choice. > This machine also has the "Intel(R) Integrated Graphics Media > Accelerator X3100". Is that just another way of saying "integrated > video"? Several of my other machines have had integrated video and it > does seem to drag down the CPU noticeably. Any idea if I will notice > the drag on the Core 2 Duo? They also offer an Nvidia Gforce 8400 GS > adapter for $100 and an 8600 for $200 more. Any idea if these are For the 2D realm it'll make no noticeable difference. If 3D's your bag (basically games) then integrated video is pretty hopeless. On the brightside integrated video will increase battery life which is always a bonus. > worth it? The 1500 says it has "VGA video output & S-Video". Does > that mean I can connect two monitors for dual display? Probably not. I suspect it means you can connect the laptop to a VGA monitor, or TV with S-Video input. Note that while S-Video is OK for watching a film, it's hopeless for actual work (unless you like headaches). > The CPU is a T5270 (1.4 GHz, 2 MB cache) with upgrades to various > processors for significant money. The first stepup is to a T5470 (1.6 > GHz) for $75 and others range up to $575! I am thinking I can live > with the slower processor. The memory is 2GB. Unless you can bump it up to a 4Mb cache version, I doubt the extra $100's for a few MHz is going to make all that much difference. 2GB memory is about the most that XP can reasonably handle anyway, unless you fancy playing with 64bit linux which is always an option (hint - repartition the drives and reinstall windows the second you get the laptop if you are even considering this option). > I was looking at the Vostro 1000 earlier this week with an AMD TK-53 > processor (1.5 GHz, 512 KB cache) and a smaller hard drive. It was > $50 more so the 1500 looks like the better deal. Are there any > significant differences in the two CPUs for FPGA work? I guess the > small cache of the TK-53 would make it significantly slower for FPGA > work. Dunno - the biggest difference I've found with a dual core machine is that I can continue working thanks to the second processor. Now I'm not waiting for it to finish all the time, I care a good bit less about how long it takes. Cheers, AndyArticle: 126215
In article <473e2dbe.1233804717@news.planet.nl>,
Nico Coesel <nico@puntnl.niks> wrote:
>I have a customer which has a lot of legacy in schematics (Orcad/ XNF
>format) which is totally useless with the newer ISE versions. Their
>VHDL code however ports nicely between various ISE versions.
So is this DOS OrCAD or Windows OrCAD? I have a very rough tool which
converts DOS OrCAD into Verilog. If there's interest I'll post it.
--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 126216Hi, can anybody help in providing a document or any site relating gate count calculation in xilinx. Thanks & regards subbuArticle: 126217
"austin" <austin@xilinx.com> wrote in message news:fhl3m9$19o1@cnn.xilinx.com... > All, > > That would make no sense at all (to have a TI DSP soft core) in an FPGA! > That's like saying it makes no sense at all to have a powerpc or a microblaze in an FPGA? I have a v4fx system, I'd like a dsp coprocessor. I don't want to waste the board space or power consumption for a dedicated DSP since not all applications will need/use it. For wideband signal processing apps I can use the fpga fabric, for narrowband stuff I can use a softcore with floating point DSP. -ClarkArticle: 126218
Hi, Can anybody help me in providing a document or site in gate count calculation in Xillinx Spartan 3E. thanks & regard subbuArticle: 126219
On Nov 16, 9:10 pm, subbu <subramanian.2k...@gmail.com> wrote: > Hi, > Can anybody help me in providing a document or site in gate count > calculation in Xillinx Spartan 3E. > thanks & regard > subbu Gate-count is a meaningless metric for FPGAs, where functionality is implemented in coarser chunks, like LUTs and BlockRAMs, DSP slices, sophisticated I/O etc. Marketing might be tempted to claim inflated numbers, which would create howling comments from the user community. Just don't dive into this rat-hole ! Count instead flip-flops = Logic Cells, and then evluate the more dedicated functions, like memories and multipliers/accumulators. Peter Alfke, Xilinx ApplicationsArticle: 126220
On 16 Nov., 19:04, Duane Clark <junkm...@junkmail.com> wrote: > u_stad...@yahoo.de wrote: > > hi > > > ich have a problem with a project in ise and modelsim. i used the core > > generator to create a single port block memory and instantiated it in > > my design. now i want to do a behavioral simulation to verify my > > design. i followed the instructions from the core generator help file. > > ( i used the *.vho file to instantiate the block memory in my design > > and downloaded the latest libraries from xilinx for model sim). > > Hopefully it won't be too annoying if I avoid actually answering your > question, and instead suggest that you not use core generator to > instantiate simple memories. You really should infer them. For example, > yours might look something like: > > type mem_array is array(0 to 511) of std_logic_vector(31 downto 0); > signal ram : mem_array; > > -- infer block RAM > wr_p: process(CLK) > begin > if rising_edge(CLK) then > if s_write_Strobe = '1' then > ram(to_integer(Address)) <= Data_in; > end if; > end if; > end process wr_p; > rd_p: process(CLK) > begin > if rising_edge(CLK) then > rd_addr_ram <= Address; > end if; > end process rd_p; > Data_Out <= ram(to_integer(rd_addr_ram)); > > Notice that it is important to register the read address. This is > required to infer block ram. If you don't do that, you will get LUT ram. thanks for the hint how to infer block ram. i will try that out! (why istn't it a good idea to use the core generator for simple block memory? just beauty reasons?) i still would be curious though what's wrong the way i tried it?!? can you give me a hint there? thanks urbanArticle: 126221
Austin, Does that mean Xilinx has something in the pipeline? Luc On Fri, 16 Nov 2007 07:57:00 -0800, austin <austin@xilinx.com> wrote: >Colin, > >If you email me directly what size ECP2M part you are considering, and >if you work with a distributor or FAE (who is your contact for Xilinx), >I will have someone get back to you. > >AustinArticle: 126222
<psihodelia@googlemail.com> wrote in message news:c143798e-856e-4be4-8384-15c3a4e79573@b32g2000hsa.googlegroups.com... > Just look at its syntax. It is so archaic that anyone who had any deal > with Python will just laugh. Try, say, to create a simple VGA > controller, which is simply readable. Ok, in that case start writing your VGA controller in Python, then go to http://myhdl.jandecaluwe.com/doku.php/start synthesize it, download it on an FPGA prototype board and report back to us how incredible simple and quick it was.... :-) > Conceptually VHDL is not bad at all, it supports a lot of things, well > in theory. But in praxis ... Praxis....isn't that a DIY store in Holland? Hans www.ht-lab.com > > VHDL's Ada syntax is also very error prone. Instead of having all this > archaic constructions and surplus operators, it would be much more > productive just to start thinking about to create another hi-level HDL > that has absolutely another conceptual design and simple syntax. > > Any good language should be so simple as possible and any program in > this language should be short and clear. Such language should support > associative arrays, that should help designing large FSMs; should > support simple mechanism of type conversions and so on... > > Conceptually VHDL is not bad at all, it supports a lot of things, well > in theory. But in praxis ... > > And don't forget about future FPGAs, about future SoCs, which will > have integrated MEMS arrays, and other stuff. Try to understand how > much complexer they are to be designed in so unproductive way using so > primitive languages.Article: 126223
> Any good language should be so simple as possible and any program in > this language should be short and clear. A reminder : VHDL is not a programming language, thus implying you do not write a program with VHDL.Article: 126224
In news:c143798e-856e-4be4-8384-15c3a4e79573@b32g2000hsa.googlegroups.com timestamped Fri, 16 Nov 2007 10:27:59 -0800 (PST), "psihodelia@googlemail.com" <psihodelia@googlemail.com> posted: |-----------------------------------------------------------------------| |"Just look at its syntax. It is so archaic that anyone who had any deal| |with Python will just laugh. [..]" | |-----------------------------------------------------------------------| Nonsense. |-----------------------------------------------------------------------| |VHDL's Ada syntax is also very error prone. Instead of having all this | |archaic constructions and surplus operators," | |-----------------------------------------------------------------------| I disagree that any of VHDL and Ada has error-prone syntax. Please provide examples. |-----------------------------------------------------------------------| |" it would be much more | |productive just to start thinking about to create another hi-level HDL | |that has absolutely another conceptual design and simple syntax." | |-----------------------------------------------------------------------| Does reFLect not fit your needs. What about Lava or Hawk or APL or Confluence or Verischemelog or any of the other supposedly high-level terse languages which have been proposed for hardware (not that APL had originally been proposed for hardware, but at least one paper for hardware with APL had been published). |---------------------------------------------------------------------| |"Any good language should be so simple as possible and any program in| |this language should be short and clear. Such language should [..] | |should help designing large FSMs; [..] | | | |[..]" | |---------------------------------------------------------------------| So despite your claim that VHDL is out of date and your mention of Python earlier, should your advocacy of state machines be construed as evidence that you oppose object orientation?
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