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
Dek, It is a warning: you do not necessarily have to fix it. The tools are telling you that a net to a constant (1=power, or 0=ground) had its timing constraint removed (ignored). That is a perfectly OK thing to do. It is up to you to read each warning, and check out what it means. This one is easy, let it go. AustinArticle: 145751
Ok thanks all for your help. I will try using diferent DCM for each MGT. I hope that works. --- frmsrcurl: http://compgroups.net/comp.arch.fpga/rocketio-TX-delay-between-sata0-and-sata1Article: 145752
On Feb 21, 8:02=A0pm, Rick <richardcort...@gmail.com> wrote: > On Feb 21, 2:02=A0pm, Derek Simmons <dereks...@gmail.com> wrote: > > > > > On Feb 5, 1:19=A0pm, Eric Chomko <pne.cho...@comcast.net> wrote: > > > > Has anyone created a copy machine of an old system using an FPGA? I > > > was wondering if it would be possible to take an entire SWTPC 6800 an= d > > > compile the schematics and have it run on an FPGA board.? Wouldn't > > > even have to be the latest Xylinx product, I suspect. > > > In Circuit Cellar's 2009 issue is the article, "Retrocomputing on an > > FPGA: Reconstructing an '80s-Era Home Computer with Programmable > > Logic". The author describes his experience of designing a Apple II+ > > compatiable project. > > > Another project I know of is mentioned at: > > >http://vector-graphic.info/vg_links.aspx > > > This whole website is dedicated to Vector Graphic S-100 computers. The > > link half way down the page is wrong but the project can be found at: > > >http://opencores.org/project,vg_z80_sbc > > > At this web is 8086 core: > > >http://www.ht-lab.com/freecores/cpu8086/cpu86.html > > > I believe the sample project with the core would be equivalent of a > > 8086 SBC running DOS. > > > Derek > > NOT a FPGA but certainly a design I would like to see executed in FPGA > and very vintagehttp://laughtonelectronics.com/arcana/BrideOfSonPg1.html > > He used a 65C02 and a KIM as his starting point. The 65C02 was chosen > because all > of its unimplemented instructions became NOPs. If I have it right, he > then intercepts > the unused op codes and uses them for his own purposes like extending > the memory > addressing. It is an interesting design in that when you move the > microcode off the > main processor you can optimize the system for very specific tasks. In > his case he > used it for running Forth. > > I guess the argument could be just do the entire thing in VDHL or use > the right processor > for the job.<grin> Instruction set problems seem to come up fairly > often. I *think* some > C implementations could use a separate hardware stack for instance. > > Rick A hardware stack for C is a bit of a problem. C tends to need a rather large stack because of the stack frames used. A language like Forth, on the other hand, can get by with a very small hardware stack because the stack usage tends to be minimal and subroutine nesting does not automatically add to the data stack depth. Instead, often parameters that are passed into one routine are also passed onto the next without duplication until they are consumed by the calculations that need them. In c every call copies every piece of data needed for the lower level code creating stack "bloat" if you will. There are any number of Forth CPU designs, many of which use a hardware dedicated stack for data and another for addresses. RickArticle: 145753
On 22 f=E9v, 07:56, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > Most of what's been posted is good advice. > > I usually split design into functional blocks which can then > be indepentantly functionally tested, these are my entities. > > When it comes to signal routing I had to pick up a design a while > ago that used records all over the place. I found this obscured the > functional intent and made it much more difficult to debug so I'm not > a big fan, although I have used them in a couple of instances. > > Keep it all as simple as possible! > > Nial. I think that records that group "related logic" make design clearer. The important thing is not to group random signals in a record. For example, I use records to interface my sdram controller with my other processing blocks. One record is called "sdram_if_input_t" for the sdram controller interface inputs and the other one "sdram_if_output_t" for the controller outputs. Therefore my block called "video_processing" is connected by 2 signals to the sdram controller instead of being connected by 10-15 signals to the sdram controller. That way the top level is much much clearer since the number of signals is reduced. The possibility of errors is reduced too because there's less risk of connecting the wrong signal in the wrong place with records. For entities, I think that if you have trouble saying what is the purpose of the block you're designing, then your block is probably doing too much or not enough. That's what I aim for. That way it's easier to reuse the block and the testbench design is also easier. I also try to use only one process for my entities when possible (After looking at Mike Treseler's code). BenjaminArticle: 145754
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote: (big snip) > A hardware stack for C is a bit of a problem. C tends to need a > rather large stack because of the stack frames used. It depends, somewhat, on the programmer. In K&R C, you couldn't pass a struct, but instead a pointer to a struct. That kept the stack a little smaller, at least. With C89, as with K&R, arrays (including automatic, allocated on the stack) had a constant dimension. If I remember right, C99 added the ability to dimension local automatic (stack) arrays with variables. (Previously, a pointer on the stack and malloc() would have been used, along with the requirement to remember free().) > A language like > Forth, on the other hand, can get by with a very small hardware stack > because the stack usage tends to be minimal and subroutine nesting > does not automatically add to the data stack depth. Instead, often > parameters that are passed into one routine are also passed onto the > next without duplication until they are consumed by the calculations > that need them. In c every call copies every piece of data needed for > the lower level code creating stack "bloat" if you will. If you only pass pointers, it isn't so bad... -- glenArticle: 145755
On Feb 20, 10:24=A0am, Petter Gustad <newsmailco...@gustad.com> wrote: > Or interfaces if you're using SystemVerilog. Interfaces can carry > signals which run in both directions. VHDL records can only carry > signals running in a single direction. A record port can only have a single mode, but it can be inout. multi- directioned records require resolved types and default drivers defined everywhere those elements are used only as inputs. It requires a lot of work down below, but at the top level, plumbing is sweet easy to maintain. Need another signal? Just add it to the record type and to the default undriven value constant, then you only need to patch it in where it is ultimately used. User defined collections of per-element modes for records has been on my Christmas list for a long time... AndyArticle: 145756
As you've probably guessed, there is no one "best way" to partition a design. A much under-used method (IMHO) is that of vhdl blocks. Blocks are like entities/architectures, but you don't have to specify the ports. You can specify signals and objects that are local to that block, and not visible anywhere else, but objects declared outside the block are visible inside it. For instance, if I had a set of entities or processes that shared a set of signals amongst themselves, but not anywhere else, I could use a block to encapsulate those entities/processes along with their locally interconnecting signals, yet not have the overhead of passing external interfaces through yet another layer of ports. AndyArticle: 145757
Dek wrote: > I was thinking to follow this implementation: > > http://www.itee.uq.edu.au/~peters/xsvboard/stack/stack.htm great link but where are the VHDL source files ? > Dek yg -- http://ygdes.com / http://yasep.orgArticle: 145758
JuNNi wrote: > Hi, I am a beginner at FPGA. I had a query that which platform is used for > professional digital designs. Is it linux or windows?? > > > > --------------------------------------- > Posted through http://www.FPGARelated.com Hi, Altera support Vista 32 bit, XP 32 bit and some Linux. If you use the free web edition https://www.altera.com/support/software/download/altera_design/quartus_we/dnl-quartus_we.jsp on a modern fast PC (less that 2 years old) and with at least 2 GB of ram you should be fine for learning about FPGAs. JamesArticle: 145759
On Feb 22, 2:27=A0pm, rickman <gnu...@gmail.com> wrote: > On Feb 21, 8:02=A0pm, Rick <richardcort...@gmail.com> wrote: > > > > > On Feb 21, 2:02=A0pm, Derek Simmons <dereks...@gmail.com> wrote: > > > > On Feb 5, 1:19=A0pm, Eric Chomko <pne.cho...@comcast.net> wrote: > > > > > Has anyone created a copy machine of an old system using an FPGA? I > > > > was wondering if it would be possible to take an entire SWTPC 6800 = and > > > > compile the schematics and have it run on an FPGA board.? Wouldn't > > > > even have to be the latest Xylinx product, I suspect. > > > > In Circuit Cellar's 2009 issue is the article, "Retrocomputing on an > > > FPGA: Reconstructing an '80s-Era Home Computer with Programmable > > > Logic". The author describes his experience of designing a Apple II+ > > > compatiable project. > > > > Another project I know of is mentioned at: > > > >http://vector-graphic.info/vg_links.aspx > > > > This whole website is dedicated to Vector Graphic S-100 computers. Th= e > > > link half way down the page is wrong but the project can be found at: > > > >http://opencores.org/project,vg_z80_sbc > > > > At this web is 8086 core: > > > >http://www.ht-lab.com/freecores/cpu8086/cpu86.html > > > > I believe the sample project with the core would be equivalent of a > > > 8086 SBC running DOS. > > > > Derek > > > NOT a FPGA but certainly a design I would like to see executed in FPGA > > and very vintagehttp://laughtonelectronics.com/arcana/BrideOfSonPg1.htm= l > > > He used a 65C02 and a KIM as his starting point. The 65C02 was chosen > > because all > > of its unimplemented instructions became NOPs. If I have it right, he > > then intercepts > > the unused op codes and uses them for his own purposes like extending > > the memory > > addressing. It is an interesting design in that when you move the > > microcode off the > > main processor you can optimize the system for very specific tasks. In > > his case he > > used it for running Forth. > > > I guess the argument could be just do the entire thing in VDHL or use > > the right processor > > for the job.<grin> Instruction set problems seem to come up fairly > > often. I *think* some > > C implementations could use a separate hardware stack for instance. > > > Rick > > A hardware stack for C is a bit of a problem. =A0C tends to need a > rather large stack because of the stack frames used. =A0A language like > Forth, on the other hand, can get by with a very small hardware stack > because the stack usage tends to be minimal and subroutine nesting > does not automatically add to the data stack depth. =A0Instead, often > parameters that are passed into one routine are also passed onto the > next without duplication until they are consumed by the calculations > that need them. =A0In c every call copies every piece of data needed for > the lower level code creating stack "bloat" if you will. I'm pretty sure ALGOL and PL/I are far worse WRT to stack bloat than is C. But yes, nothing would beat FORTH unless you used assembly and only architectures with HW stacks. Two being better than one (i.e. 6809 vs 6800). > There are any number of Forth CPU designs, many of which use a > hardware dedicated stack for data and another for addresses. Years ago I worked as a research assistant with a professor doing High- Level Architectures. I suggested Forth and he sort of poo-pooed the idea mostly because his grant was from the Air Force and they were all about using JOVIAL at that time. This was pre-RISC days and the whole computer architecture idea based upon a high-level language never really took off. Nor did the use of a medium level language like Forth as far as I can tell. EricArticle: 145760
In comp.arch.fpga Eric Chomko <pne.chomko@comcast.net> wrote: (snip) > I'm pretty sure ALGOL and PL/I are far worse WRT to stack > bloat than is C. ALGOL, PL/I, and C pretty much require local variables to be automatic. (PL/I procedures without the RECURSIVE attribute might get away with static allocation.) Fortran up through Fortran 77 allowed local variables to be statically allocated. Without the RECURSIVE attribute, it probably still does. Other than passing of arguments, it depends on how you allocate your variables. PL/I has the STATIC attribute which will keep variables off the stack, as does C. Be careful with recursion, though. For ALGOL, maybe you need internal procedures using variables from outside, and to minimize actual local variables. PL/I can easily generate temporary variables, including arrays. > But yes, nothing would beat FORTH unless you used assembly and only > architectures with HW stacks. Two being better than one (i.e. 6809 vs > 6800). -- glenArticle: 145761
glen herrmannsfeldt wrote: > In comp.arch.fpga rickman <gnuarm@gmail.com> wrote: > (big snip) > >> A hardware stack for C is a bit of a problem. C tends to need a >> rather large stack because of the stack frames used. > > It depends, somewhat, on the programmer. In K&R C, you couldn't > pass a struct, but instead a pointer to a struct. That kept > the stack a little smaller, at least. With C89, as with K&R, > arrays (including automatic, allocated on the stack) had a > constant dimension. If I remember right, C99 added the ability > to dimension local automatic (stack) arrays with variables. > (Previously, a pointer on the stack and malloc() would have > been used, along with the requirement to remember free().) > And even though structs *can* be passed to and returned from functions, a programmer is *not* forced to do that. One can still pass the pointers to structs. One can still use "malloc()" and "free()" to allocate variable-size arrays. If you are an "old time" C programmer, this probably fits better in your way of thinking. In any case, if it is important to conserve stack space, the "good ole ways" can still be used. -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+Article: 145762
Eric Chomko wrote: > > I'm pretty sure ALGOL and PL/I are far worse WRT to stack bloat than > is C. PL/I can be, but doesn't have to be. If the arguments of a procedure match the parameters, only the argument address (and possibly a descriptor address for strings structures, and arrays) is passed. If the argument doesn't match, the compiler nicely copies it to a "dummy argument" that does. As usual, the programmer needs to have some idea what's going on.Article: 145763
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: >In comp.arch.fpga rickman <gnuarm@gmail.com> wrote: >(big snip) > >> A hardware stack for C is a bit of a problem. C tends to need a >> rather large stack because of the stack frames used. > >It depends, somewhat, on the programmer. In K&R C, you couldn't >pass a struct, but instead a pointer to a struct. That kept >the stack a little smaller, at least. With C89, as with K&R, >arrays (including automatic, allocated on the stack) had a >constant dimension. If I remember right, C99 added the ability >to dimension local automatic (stack) arrays with variables. >(Previously, a pointer on the stack and malloc() would have >been used, along with the requirement to remember free().) Some C implementations supported alloca() which would allocate on the stack (and would be automatically free'd on return). A minimal C stack frame is the return instruction pointer, with arguments passed in registers. scottArticle: 145764
On Feb 21, 6:03=A0pm, marcelo <u...@compgroups.net/> wrote: > yes I understand but 500ps is to much for pcb delay, are 15cm. > The idia is ti desing an ultra wideband transmiter using the MGT. > I'm using BPKS modulation, so the delay between TX1(positive pulse) and T= X2(negativo pulse), must be the same. > > --- > frmsrcurl:http://compgroups.net/comp.arch.fpga/rocketio-TX-delay-between-= sata0-... 500pS is 7.7cm assuming 65pS/cm in typical FR-4 material. I'm not a RF DSP expert, but why do you need two separate transmitters for this design? What component are the transmitters connected to in the system? Ed McGettigan -- Xilinx Inc.Article: 145765
On 22 Feb, 00:45, Derek Simmons <dereks...@gmail.com> wrote: > I realize what I'm looking for might not be out there anymore but I'm > trying to give it my best shot. > > A couple of years ago I came across a website that somebody put up > describing an ultimate RISC or MISC processor they were developing. > One of their goals was to be able to run LINUX on it. Was having a > conversation with of friend of mine that made me think of this and I > wondered if they ever achieved their goal. > > I think his processor had 16 different instructions and they had > implemented it using an FPGA. > > Does this sound familair to anybody? > > Thanks, > Derek Can't think of it, the linux thing. Doing processor design myself, but not interested in booting linux as a primary goal. Getting a boot loader written to load flash into the 128K memory is my goal. Then filling the boot sectors of the flash. I think after a little bit of thought, I will get the on chip flash to be twice as effective almost, by not using the MSB of the 16 bit word. But that's another day. cheers jacko http://nibz.nibzx.co.ukArticle: 145766
whygee <yg@yg.yg> writes: >Dek wrote: >> I was thinking to follow this implementation: >> >> http://www.itee.uq.edu.au/~peters/xsvboard/stack/stack.htm >great link but where are the VHDL source files ? >> Dek >yg >-- >http://ygdes.com / http://yasep.org on the project home page above that at in a zip file. http://www.itee.uq.edu.au/~peters/xsvboard/index.html Peter Van EppArticle: 145767
I need two transmiters, because I transmit BPSK pulse so positive and negative pulses. The time bettwen pulses is 150 ns, so if I change the polarity of MGT, the output capacitor of the bord charge and discharge so I can't see the pulse at the output. I don't know what hapen if I remove this capacitors. thanks --- frmsrcurl: http://compgroups.net/comp.arch.fpga/rocketio-TX-delay-between-sata0-and-sata1Article: 145768
On Feb 22, 6:02=A0pm, Marcelo Segura <u...@compgroups.net/> wrote: > I need two transmiters, because I transmit BPSK pulse so positive and neg= ative pulses. > The time bettwen pulses is 150 ns, so if I change the polarity of MGT, th= e output capacitor of the bord charge and discharge so I can't see the puls= e at the output. > I don't know what hapen if I remove this capacitors. > thanks > > --- > frmsrcurl:http://compgroups.net/comp.arch.fpga/rocketio-TX-delay-between-= sata0-... I don't understand what you mean here, is there a diagram somewhere on the web that illustrates what you are attempting to do? Ed McGettigan -- Xilinx Inc.Article: 145769
On Feb 18, 1:13=A0pm, rickman <gnu...@gmail.com> wrote: > On Feb 18, 11:10=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > > > On Feb 17, 7:51=A0pm, rickman <gnu...@gmail.com> wrote: > > > > On Feb 17, 8:05 pm, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > On Feb 17, 4:29 pm, rickman <gnu...@gmail.com> wrote: > > > > > Fight fire with fire! =A0The two reports below show that both the > > > > > missing else and the missing assignment (which is also missing in= the > > > > > missing else case) produce latches. > > > > > > @W: CL117 :"C:\arius\boards\tdc_upgrade\tests\latchsynthtest.vhd"= : > > > > > 57:4:57:7|Latch generated from process for signal Latch, probably > > > > > caused by a missing assignment in an if or case stmt > > > > > @W: CL117 :"C:\arius\boards\tdc_upgrade\tests\latchsynthtest.vhd"= : > > > > > 40:4:40:7|Latch generated from process for signal Comb, probably > > > > > caused by a missing assignment in an if or case stmt > > > > > > library ieee; > > > > > use ieee.std_logic_1164.all; > > > > > use ieee.numeric_std.all; > > > > > > entity LatchSynthTest is > > > > > =A0 port( > > > > > =A0 =A0 =A0 =A0 =A0 CLK =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : in = =A0 =A0std_logic ; > > > > > =A0 =A0 =A0 =A0 =A0 RESET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : in = =A0 =A0std_logic ; > > > > > =A0 =A0 =A0 =A0 =A0 C01 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : in = =A0 =A0std_logic ; > > > > > =A0 =A0 =A0 =A0 =A0 C02 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : in = =A0 =A0std_logic ; > > > > > =A0 =A0 =A0 =A0 =A0 LatchOutput =A0 : out =A0 std_logic ; > > > > > =A0 =A0 =A0 =A0 =A0 CombOutput =A0 =A0: out =A0 std_logic > > > > > =A0 =A0 =A0 =A0 =A0 ); > > > > > end LatchSynthTest ; > > > > > > architecture behavior of LatchSynthTest is > > > > > =A0 SIGNAL Latch =A0 =A0 =A0 =A0 =A0: std_logic; > > > > > =A0 SIGNAL Comb =A0 =A0 =A0 =A0 =A0 : std_logic; > > > > > =A0 SIGNAL LatchReg =A0 =A0 =A0 : std_logic; > > > > > =A0 SIGNAL CombReg =A0 =A0 =A0 =A0: std_logic; > > > > > > begin > > > > > > =A0 CombOutput =A0 =A0<=3D CombReg; > > > > > =A0 LatchOutput =A0 <=3D LatchReg; > > > > > > =A0 Process_1 : process(RESET, CLK) > > > > > =A0 begin > > > > > =A0 =A0 if (RESET =3D '1') then > > > > > =A0 =A0 =A0 LatchReg =A0<=3D '0'; > > > > > =A0 =A0 =A0 CombReg =A0 <=3D '0'; > > > > > =A0 =A0 elsif (rising_edge(CLK)) then > > > > > =A0 =A0 =A0 LatchReg =A0<=3D Latch; > > > > > =A0 =A0 =A0 CombReg =A0 <=3D Comb; > > > > > =A0 =A0 end if; > > > > > =A0 end process; > > > > > > =A0 CombProc : process(CombReg, C01, C02) > > > > > =A0 begin > > > > > =A0 =A0 case CombReg is > > > > > =A0 =A0 =A0 when '0' =3D> > > > > > =A0 =A0 =A0 =A0 if (C01 =3D '1') then > > > > > =A0 =A0 =A0 =A0 =A0 Comb <=3D '0'; > > > > > =A0 =A0 =A0 =A0 elsif (C02 =3D '1') then > > > > > =A0 =A0 =A0 =A0 =A0 Comb <=3D '1'; > > > > > =A0 =A0 =A0 =A0 else > > > > > =A0 =A0 =A0 =A0 =A0 -- Here an assignment statement is missing, b= ut it doesn't > > > > > =A0 =A0 =A0 =A0 =A0 -- generate latch. =A0It is treated as a null= statement. - > > > > > Weng > > > > > =A0 =A0 =A0 =A0 end if; > > > > > =A0 =A0 =A0 when others =3D> > > > > > =A0 =A0 =A0 =A0 Comb <=3D '1'; > > > > > =A0 =A0 end case; > > > > > =A0 end process; > > > > > > =A0 LatchProc : process(LatchReg, C01, C02) > > > > > =A0 begin > > > > > =A0 =A0 case LatchReg is > > > > > =A0 =A0 =A0 when '0' =3D> > > > > > =A0 =A0 =A0 =A0 if C01 =3D '1' then > > > > > =A0 =A0 =A0 =A0 =A0 Latch <=3D '0'; > > > > > =A0 =A0 =A0 =A0 elsif C02 =3D '1' then > > > > > =A0 =A0 =A0 =A0 =A0 Latch <=3D '1'; > > > > > =A0 =A0 =A0 =A0 =A0 -- Here the else is missing, and it does > > > > > =A0 =A0 =A0 =A0 =A0 -- generate latch. =A0It is treated as a null= statement. > > > > > =A0 =A0 =A0 =A0 end if; > > > > > =A0 =A0 =A0 when others =3D> > > > > > =A0 =A0 =A0 =A0 Latch <=3D '1'; > > > > > =A0 =A0 end case; > > > > > =A0 end process; > > > > > > end behavior; > > > > > Hi, > > > > Thank you, Andy, Rick and everyone, I am wrong in the second point: > > > > missing "else" or missing an assignment statement. > > > > > But my first point is how to generate a latch for a compiler. Rick, > > > > can you see the floor plan to show how the latch is generated: for = the > > > > state only or for full states? > > > > > Weng > > > > I'm not clear what you mean by "how". =A0Are you asking about the det= ail > > > of how it is implemented in the FPGA? =A0In the Lattice part they use= d a > > > FF as a latch. =A0A register is between the latch and the output. =A0= They > > > drive the latch oddly driving both the clock and the async reset > > > inputs with logic, but then if you look at the code what would you > > > think is the clock? =A0I don't see why they did it the way they did, = but > > > it works correctly according to the VHDL. =A0With only four inputs I > > > would expect they could have just used a single LUT4 and the latch > > > with the clock always enabled. > > > > Din =3D=3D '1' > > > Latch Enable =3D=3D CombReg + C02 > > > Async Clear =A0=3D=3D ~CombReg * C01 > > > > Is this what you are asking? > > > > Rick > > > Rick, > > Yes, that is what I want. > > > Could you please send the code and a window screen frame using > > Window's Paint so that I can see the full picture. > > > Thank you. > > > Weng > > I'm not clear on what you want. =A0I posted the full code a couple of > posts back. =A0What is it that you want a screen shot of? =A0The text I > quoted was from the Synthesis report. =A0If you want an image of the > chip editor, the latch only shows in the logic block editor dialog > box. =A0It is just a check box on a schematic of the functional elements > in the logic block. =A0Is that of any value to you? > > Rick Rick, Thank you for your help. This time I really understand what the Lattice does with your source code in the previous poster. Lattice generates a latch for the process of CombProc, paying no attention to what is used. And I think Lattice compiler does a very good job by generating the following equations: Din =3D=3D '1' Latch Enable =3D=3D CombReg + C02 Async Clear =3D=3D ~CombReg * C01 "With only four inputs I would expect they could have just used a single LUT4 and the latch with the clock always enabled. " No. What you suggest may not work. Or it may work, but is not as simple as the Lattice equations show. I would like to see how you would write a LUT4 equation for a latch. WengArticle: 145770
Peter Van Epp wrote: >> great link but where are the VHDL source files ? > on the project home page above that at in a zip file. > http://www.itee.uq.edu.au/~peters/xsvboard/index.html oh thanks again, I completely missed it :-/ > Peter Van Epp yg -- http://ygdes.com / http://yasep.orgArticle: 145771
On 22 Feb., 14:12, "JuNNi" <m_junaid_muzam...@yahoo.com> wrote: > Hi, I am a beginner at FPGA. I had a query that which platform is used for > professional digital designs. Is it linux or windows?? For normal FPGA Design Windows is common, as some (backend-) FPGA tools are either Windows only or show better performance under Windows. For general digital design (and especially frontend of code entry and simulation) professionals use often Linux/Solaris when it comes to complex and large designs. One reason for using Linux/Solaris is, that handling of large designs requires often more than 2GB memory, but especially those tools mentioned above that are Windows only or show bad performance under Linux tend to be Win32 only or show bad performance in Win64 server systems. A rule of thumb: simple free starter kits are more on the Windows side, professional tools could be better used on Linux Server. bye ThomasArticle: 145772
On Feb 22, 12:27=A0pm, rickman <gnu...@gmail.com> wrote: > A hardware stack for C is a bit of a problem. =A0C tends to need a > rather large stack because of the stack frames used. What could happen, though, on a computer with a small hardware stack is that the compiler would use a software stack for things like subroutine calls (which must always work, no matter how deeply they are nested) and use the hardware stack for things it can control - such as the layers of parentheses in assignment statements. That, for example, is presumably how one would go about writing a C compiler for a KDF 9. John SavardArticle: 145773
On 23/02/2010 09:39, in article e59b10e9-83f7-4fb6-8ecf-a9d8fd13f055@v25g2000yqk.googlegroups.com, "Quadibloc" <jsavard@ecn.ab.ca> wrote: > On Feb 22, 12:27 pm, rickman <gnu...@gmail.com> wrote: > >> A hardware stack for C is a bit of a problem. C tends to need a >> rather large stack because of the stack frames used. > > What could happen, though, on a computer with a small hardware stack > is that the compiler would use a software stack for things like > subroutine calls (which must always work, no matter how deeply they > are nested) and use the hardware stack for things it can control - > such as the layers of parentheses in assignment statements. > > That, for example, is presumably how one would go about writing a C > compiler for a KDF 9. The way the Algol 60 compilers on KDF9 worked is well documented. The Whetstone compiler generated its own Algol-oriented byte code, which is very similar to the slightly later B6500 machine code. The Kidsgrove and EGDON compilers generated KDF9 machine code. Managing the hardware stacks difficult, as it would have needed global data flow and control flow analyses. The Kidsgrove compiler made a basic but not very successful attempt at this. See <http://sw.ccs.bcs.org/KidsgroveAlgol/INDEX.HTM>. -- Bill Findlay <surname><forename> chez blueyonder.co.ukArticle: 145774
Don't make the methodology of I/O and module partitioning any more complicated than it needs to be. As several have mentioned, keeping it simple goes a long way toward debugging your design faster and allowing others to understand the code when it comes to future enhancements, mods, bug fixes, etc. That being said, IMO records add a level of complexity--albeit add some power at your disposal--that isn't necessary for most of your simpler architectures. As far as partitioning goes, I like to block out modules (or entities) into well- defined functions, much like you would create one of your "blocks" in a block diagram.
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