Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On 14 Mar, 20:28, Walter Banks <wal...@bytecraft.com> wrote: > Jacko wrote: > > Feel free to make a BSD 1 bit version of nibz. It may be smaller, but > > will take 16 times as long to execute any code, yet will be bigger > > than 1/16th the size. Therefore the computational use density > > (instructions per cycle per area (m^2.s)^-1) will decrease. If > > resources are really tight to maintain budget, and the lower execution > > speed is not relevant for the task, then maybe the power efficiency > > implications of computational use density (CUD) are not important > > either. > > A very first order metric. I am not arguing for bit serial processors > but the 16 to 1 makes an assumption that the bit serial is only > implementing a 16 bit data path. A well designed bit serial instruction > set would change the metrics on both the hardware and the > performance. Yes, this is true of any new metric idea. The general wanted measure is to get bigger if less standing logic (not used in a cycle) exists. It also should encompass motion forward through a piece of code, and a lower area for function. Higher order versions of the metric should include the amount of instruction RAM/ROM area to perform a particular task, as this memory also contributes to the micro-watt per unit of computation. I do not think nibz is a perfect thing, but it comes from a lot of hours spent thinking, this is one of the main reasons for zero instruction overheads (in code size) of the design. As soon as the base routine set is defined at 4 bits per instruction. The high zero's exist only if the designer does not choose a different start vector (0) or does not place the nibble RAM/ROM in a convienient place. > You are correct that control overhead does not scale but > bit serial processors can have a bunch of viable applications > which has been my point. Low pin count to memory and I/O > for example. The SDcard gives multiple gigabytes of memory > with a few pins. Yes they do have applications with low metal/interconnect track designs. A direct sd card interface with <= 2gb and sector size of 1 word (2 bytes or 4 bytes) would be useful for all small applications. To solidify this circuit to a particular processor destroys a lot of its utility. 4 giga nibbles, ummm, would have made the 4004 quite a beast. cheers jackoArticle: 138926
On Sat, 14 Mar 2009 11:05:53 -0700, 'use_real_email' wrote: >I made a mistake the new range that i want to have is +16383 to -16384. >The quotient from the first division (without scaling) is always 0. So, if you left-shift the dividend by 15 places before doing the division, you get the desired 15-bit integer in your quotient, no? -- 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: 138927
"Antti.Lukats@googlemail.com" wrote:
> On Mar 14, 8:49 pm, rickman <gnu...@gmail.com> wrote:
> > On Mar 14, 11:11 am, Herbert Kleebauer <k...@unibwm.de> wrote:
> > > You have two operands and one result but there is only one data
> > > path to the serial memory. This means, you at least need one
> > > registers to temporary hold one of the operands and an address
> > > register to hold the address of the second operand. Mproz
> > Why do you need temporary registers? If the memory is serial, each
> > bit can be fetched as needed.
To fetch a bit you need the address of the bit. For two operands and
one result this makes three address registers which is more than using
a temporary register to hold one operand and only one address register
for to second operand, the result can be shifted in the temporary
register where the operand is shifted out.
> > > As far as I remember, mproz uses about 250 two-input gates, that
> > > should fit well with 65 flip-flop's.
> >
> > How about the memory? I expect that will be an order of magnitude
> > larger than the machine itself, even for a small program.
The size of the needed memory depends mostly on the application
and not on the CPU architecture.
> mproz stands for minimal.. so it is minimal in terms of instructions
> and resources
> in the tradeoff of speed (8 clocks!) and program size
>
> the machine is funny, it can do subroutine calls by patching own code
> on the fly
You don't need to patch the code (you can't patch code in ROM). You
can either use a software stack or, if the subroutine doesn't need to
be re-entrant, a fixed ram location to store the return address for
the subroutine. But indirect addressing requires self modifying
code, so you can do it only in RAM but not in ROM.
> that is self modifying code is needed, normal instructions are 6 bytes
> or 8 bytes
The jump instruction is one word (2 bytes), the add/nor instruction
4 bytes for the two address machine and 6 bytes for the three address
machine. But code density seems to be the sane for the two and three
address machine.
> if new immediate constant is needed. Also shift and rotate are very
> clumsy i guess
a left shift is simple an "add", a rotate left are three instructions:
add r0,r0 ; lsl r0
br _10 ; branch if carry not set
add #1,r0 ; set LSB
_10:
a rotate right is simple 15 times a rotate left.
> so the maximum 32K memory space would only hold say about 5K
> instructions !
The predecessor XPROZ ( http://www.bitlib.de/pub/xproz/ ) was a three
address machine with an instruction length or four 16-bit words.
A multitasking operating system with all the system utilities in a
ROM-disk still fitted in 64 kbyte ROM. The OS had drivers for a hard
disk, floppy, serial and parallel port, keyboard interface and a
graphics card.
Article: 138928On Mar 14, 9:16=A0pm, Herbert Kleebauer <k...@unibwm.de> wrote: > "Antti.Luk...@googlemail.com" wrote: > > On Mar 14, 8:49 pm, rickman <gnu...@gmail.com> wrote: > > > On Mar 14, 11:11 am, Herbert Kleebauer <k...@unibwm.de> wrote: > > > > You have two operands and one result but there is only one data > > > > path to the serial memory. This means, you at least need one > > > > registers to temporary hold one of the operands and an address > > > > register to hold the address of the second operand. Mproz > > > Why do you need temporary registers? =A0If the memory is serial, each > > > bit can be fetched as needed. > > To fetch a bit you need the address of the bit. For two operands and > one result this makes three address registers which is more than using > a temporary register to hold one operand and only one address register > for to second operand, the result can be shifted in the temporary > register where the operand is shifted out. Are you saying that the mproz has all these hidden registers? How is that different for a serial version? The serial version should be able to fetch one bit of each operand and write one bit of the result. I don't know how the machine works in detail. I didn't see anything that would explain this clearly. So I can't really say how this could work better (smaller actually) as a bit serial machine. > > > > As far as I remember, mproz uses about 250 two-input gates, that > > > > should fit well with 65 flip-flop's. > > > > How about the memory? =A0I expect that will be an order of magnitude > > > larger than the machine itself, even for a small program. > > The size of the needed memory depends mostly on the application > and not on the CPU architecture. That is a non-sequitur. This machine is *very* inefficient in its use of memory. The memory is also a resource. If the application does not require any more memory than the size of the machine, it is very unlikely that this would be smaller than a simple FSM! I think I've lost the idea of what we are discussing here. The original premise was that a parallel machine can be designed with a bit serial data path and save resources. I supposed you can always find some odd architecture where this is not true, but I would say it should at least be a practical one. > > mproz stands for minimal.. so it is minimal in terms of instructions > > and resources > > in the tradeoff of speed (8 clocks!) and program size > > > the machine is funny, it can do subroutine calls by patching own code > > on the fly > > You don't need to patch the code (you can't patch code in ROM). You > can either use a software stack or, if the subroutine doesn't need to > be re-entrant, a fixed ram location to store the return address for > the subroutine. But indirect addressing requires self modifying > code, so you can do it only in RAM but not in ROM. > > > that is self modifying code is needed, normal instructions are 6 bytes > > or 8 bytes > > The jump instruction is one word (2 bytes), the add/nor instruction > 4 bytes for the two address machine and 6 bytes for the three address > machine. But code density seems to be the sane for the two and three > address machine. > > > if new immediate constant is needed. Also shift and rotate are very > > clumsy i guess > > a left shift is simple an "add", a rotate left are three instructions: > > =A0 =A0 =A0add =A0 r0,r0 =A0; lsl r0 > =A0 =A0 =A0br =A0 =A0_10 =A0 =A0; branch if carry not set > =A0 =A0 =A0add =A0 #1,r0 =A0; set LSB > _10: > > a rotate right is simple 15 times a rotate left. > > > so the maximum 32K memory space would only hold say about 5K > > instructions ! > > The predecessor XPROZ (http://www.bitlib.de/pub/xproz/) was a three > address machine with an instruction length or four 16-bit words. > A multitasking operating system with all the system utilities in a > ROM-disk still fitted in 64 kbyte ROM. The OS had drivers for a hard > disk, floppy, serial and parallel port, keyboard interface and a > graphics card. That sounds right. Normal CPUs can host an RTOS in around 10k to 16k bytes, no? Did the mproz have a purpose? Is there anything it is especially good at in a practical way? RickArticle: 138929
On Mar 14, 3:41 pm, Samuel Thomas Kerr <stk...@cs.purdue.edu> wrote: > I'd like to design a custom microprocessor (just for learning purposes). I > used Lattice's GAL chips with ABEL before, but quickly ran out of space. > As such, I'd like to move over to an FPGA platform. > > However, I've never used FPGAs, VHDL, or Verilog before. > > I was wondering if someone could point me in the right direction? As far a > development board to start with or a book on a programming language, or > both? What you are trying to do is a very tall task, but if it is just for fun then go for it! One thing that you should know is that you don't really need hardware to work on a CPU. It is actually better if you do the vast majority of your work on paper... well, by paper, I mean in a PC. I'm an old guy, you know. You should design your instruction set and then layout an architecture to implement that instruction set. Once you have an idea of what the registers are and the data paths to connect them along with any other functional units like ALU and such, you can start coding. To test your code, you should construct a test bench. A test bench is a way to provide the environment to run your CPU in a simulation as if it were in the FPGA. You can do anything in the simulation that you can do in the FPGA with the sole limitation of the length of time. A simulation is slower than real time, so it can take seconds to simulate microseconds. I have a design that I need to simulate for 1 second to test over a full frame of data, it takes minutes to complete that. As to books, I can't recommend any VHDL books. I have five and I would not say any of them are the best, each has strengths and weaknesses. There are a number of good references available on the web, including the FAQ for this newsgroup, if my memory serves me. I would recommend that you do a search on MISC computer architectures. That is Minimal Instruction Set Computer. They are very suitable for implementation in FPGAs. The typical RISC type CPU will use much more resources in the FPGA and typically run slower. RickArticle: 138930
On Mar 15, 5:53=A0am, rickman <gnu...@gmail.com> wrote: > On Mar 14, 9:16=A0pm, Herbert Kleebauer <k...@unibwm.de> wrote: > > > "Antti.Luk...@googlemail.com" wrote: > > > On Mar 14, 8:49 pm, rickman <gnu...@gmail.com> wrote: > > > > On Mar 14, 11:11 am, Herbert Kleebauer <k...@unibwm.de> wrote: > > > > > You have two operands and one result but there is only one data > > > > > path to the serial memory. This means, you at least need one > > > > > registers to temporary hold one of the operands and an address > > > > > register to hold the address of the second operand. Mproz > > > > Why do you need temporary registers? =A0If the memory is serial, ea= ch > > > > bit can be fetched as needed. > > > To fetch a bit you need the address of the bit. For two operands and > > one result this makes three address registers which is more than using > > a temporary register to hold one operand and only one address register > > for to second operand, the result can be shifted in the temporary > > register where the operand is shifted out. > > Are you saying that the mproz has all these hidden registers? =A0How is > that different for a serial version? =A0The serial version should be > able to fetch one bit of each operand and write one bit of the > result. =A0I don't know how the machine works in detail. =A0I didn't see > anything that would explain this clearly. =A0So I can't really say how > this could work better (smaller actually) as a bit serial machine. > > > > > > As far as I remember, mproz uses about 250 two-input gates, that > > > > > should fit well with 65 flip-flop's. > > > > > How about the memory? =A0I expect that will be an order of magnitud= e > > > > larger than the machine itself, even for a small program. > > > The size of the needed memory depends mostly on the application > > and not on the CPU architecture. > > That is a non-sequitur. =A0This machine is *very* inefficient in its use > of memory. =A0The memory is also a resource. =A0If the application does > not require any more memory than the size of the machine, it is very > unlikely that this would be smaller than a simple FSM! > > I think I've lost the idea of what we are discussing here. =A0The > original premise was that a parallel machine can be designed with a > bit serial data path and save resources. =A0I supposed you can always > find some odd architecture where this is not true, but I would say it > should at least be a practical one. > > > > > > mproz stands for minimal.. so it is minimal in terms of instructions > > > and resources > > > in the tradeoff of speed (8 clocks!) and program size > > > > the machine is funny, it can do subroutine calls by patching own code > > > on the fly > > > You don't need to patch the code (you can't patch code in ROM). You > > can either use a software stack or, if the subroutine doesn't need to > > be re-entrant, a fixed ram location to store the return address for > > the subroutine. But indirect addressing requires self modifying > > code, so you can do it only in RAM but not in ROM. > > > > that is self modifying code is needed, normal instructions are 6 byte= s > > > or 8 bytes > > > The jump instruction is one word (2 bytes), the add/nor instruction > > 4 bytes for the two address machine and 6 bytes for the three address > > machine. But code density seems to be the sane for the two and three > > address machine. > > > > if new immediate constant is needed. Also shift and rotate are very > > > clumsy i guess > > > a left shift is simple an "add", a rotate left are three instructions: > > > =A0 =A0 =A0add =A0 r0,r0 =A0; lsl r0 > > =A0 =A0 =A0br =A0 =A0_10 =A0 =A0; branch if carry not set > > =A0 =A0 =A0add =A0 #1,r0 =A0; set LSB > > _10: > > > a rotate right is simple 15 times a rotate left. > > > > so the maximum 32K memory space would only hold say about 5K > > > instructions ! > > > The predecessor XPROZ (http://www.bitlib.de/pub/xproz/) was a three > > address machine with an instruction length or four 16-bit words. > > A multitasking operating system with all the system utilities in a > > ROM-disk still fitted in 64 kbyte ROM. The OS had drivers for a hard > > disk, floppy, serial and parallel port, keyboard interface and a > > graphics card. > > That sounds right. =A0Normal CPUs can host an RTOS in around 10k to 16k > bytes, no? > > Did the mproz have a purpose? =A0Is there anything it is especially good > at in a practical way? > > Rick Rick, there is. a practical reason to use. that is why i did convert the ISE SCH to plain VHDL unfortunatly my notebook HDD had a bad BOD crash stopping on CRCDISK.SYS (pevious notebook was replaced because of similar error!) so i am doing backups at the moment, but yes mproz was developed for XC2K and was great for that architecture, at the times when 64K was about maximum of RAM or EEPROM available for educational institutions AnttiArticle: 138931
On Mar 14, 3:41 pm, Samuel Thomas Kerr <stk...@cs.purdue.edu> wrote: > I'd like to design a custom microprocessor (just for learning purposes). I > used Lattice's GAL chips with ABEL before, but quickly ran out of space. > As such, I'd like to move over to an FPGA platform. > > However, I've never used FPGAs, VHDL, or Verilog before. > > I was wondering if someone could point me in the right direction? As far a > development board to start with or a book on a programming language, or > both? Starting with a clean slate is harder than taking a reference design - so look at something like Lattice Mico8, which is an 8 bit Open Source SoftCPU. http://www.latticesemi.com/products/intellectualproperty/referencedesigns/8bitmicrocontrollermico8.cfm?source=topnav This is also in both VHDL and Verilog and i see they are up to Version 3, and include older variants, so you can also study what they changed (and why) Then, modify that code, to push it in the way you want, and compare your results, with theirs. Also see the other threads on here, some have useful links, to other SoftCPUs and their trade-offs. -jgArticle: 138932
Nathan Do you happen to know how you enable this inverter? I have looked in a few documents but cant find how to enable it. There is mention of it in XAPP873 so I know it is possible. Cheers JonArticle: 138933
"maxascent" <maxascent@yahoo.co.uk> wrote:
>Nathan
>
>Do you happen to know how you enable this inverter? I have looked in a few
>documents but cant find how to enable it. There is mention of it in XAPP873
>so I know it is possible.
in VHDL:
a <= not b;
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 138934Hi, I am using "inout" signal for the first time in designing I2C communication with cmos sensor module.I have completed the design. The post map simulation worked fine and synthesized without warnings and errors. But when I implemented the design in Spartan 3A DSP by using pull up resistors for the pins I couldnot get the output.Suggest me about using the "inout" pins. Regards Dinesh.Article: 138935
Hi I dont want to infer additional logic in the fpga but use the inverter built into the IOB. I'm not sure that using that construct will work. JonArticle: 138936
On Mar 15, 2:40=A0am, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On Mar 15, 5:53=A0am, rickman <gnu...@gmail.com> wrote: > > > > > On Mar 14, 9:16=A0pm, Herbert Kleebauer <k...@unibwm.de> wrote: > > > The predecessor XPROZ (http://www.bitlib.de/pub/xproz/) was a three > > > address machine with an instruction length or four 16-bit words. > > > A multitasking operating system with all the system utilities in a > > > ROM-disk still fitted in 64 kbyte ROM. The OS had drivers for a hard > > > disk, floppy, serial and parallel port, keyboard interface and a > > > graphics card. > > > That sounds right. =A0Normal CPUs can host an RTOS in around 10k to 16k > > bytes, no? > > > Did the mproz have a purpose? =A0Is there anything it is especially goo= d > > at in a practical way? > > > Rick > > Rick, > > there is. a practical reason to use. > that is why i did convert the ISE SCH to plain VHDL > > unfortunatly my notebook HDD had a bad BOD crash > stopping on CRCDISK.SYS > (pevious notebook was replaced because of similar error!) > > so i am doing backups at the moment, > > but yes > mproz was developed for XC2K and was great > for that architecture, at the times when 64K > was about maximum of RAM or EEPROM > available for educational institutions Ok, so this is a design for a 20 year old chip family? Why is it interesting today other than for historical context? RickArticle: 138937
On Mar 15, 3:38=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote: > Hi > > I dont want to infer additional logic in the fpga but use the inverter > built into the IOB. I'm not sure that using that construct will work. > > Jon it should. all inverters should be pushed into the primitives if the inversion is available if the tools cant do this its the tools that are rotten. should be no need todo any magic AnttiArticle: 138938
"maxascent" <maxascent@yahoo.co.uk> wrote:
>Hi
>
>I dont want to infer additional logic in the fpga but use the inverter
>built into the IOB. I'm not sure that using that construct will work.
The synthesizer will deal with it. Just be sure the timing constraints
are properly specified so the synthesizer has no other choice than
using the inverter in the IOB. BTW, most XIlinx primitives have
inverters on their inputs.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 138939r = x*cos(t) + y*sin(t) is the equation of the straight line where 'r' is the length of normal to lone from origin and 't' is the angle made by normal with x axis. My problem is that I have sets of (x,y) values from which i have to calulate(r,t). So, for given (x,y) i calulate r for angle -90 to +90 and count the occurance of given (r,t) The maximum count will be (r,t) of required line so that i can calulate equation of straight line. I am doing this in microblaze using its Floating point unit for multiplication. I have created lut for sin and cos in memory. Does any one has simpler and efficient method to solve this.Article: 138940
I recently read the thread started by Jonathan Bromley, titled "Is this phase accumulator trick well-known???". I am building a DPLL and I will be using this technique. I am using a FIFO to delay data by a fixed time where the data is clocked in and out on variable rate clocks. The two clocks run at the same average rate, the input clock is gapped and the output clock is generated by the PLL to match the average of the input clock. By "clocks" I really mean clock enable just so we don't get into a big discussion on metastability and such. The requirement for a fixed time delay with a variable clock means I need to adjust the amount of data held in the FIFO as the clock speed changes. It seems to me like a proportional control of the PLL feedback using the FIFO data count will do just what I am looking for. I did some calcs and I know exactly how much data needs to be held at each clock rate. So I am going to design the phase accumulator so that the data count is used as the phase increment value. I have not analyzed the dynamic characteristics of this circuit yet, but that will be next. I just thought it was fortuitous that this discussion had come up recently to remind me of this circuit design. I worked with phase accumulators and NCOs some time back, but had forgotten most of the details. If that thread has not been posted I may well have forgotten the technique of setting the accumulator modulus to control the scale of the phase increment. Thanks! RickArticle: 138941
www.fpga4fun.comArticle: 138942
denish <dinesh.twanabasu@gmail.com> wrote: > I am using "inout" signal for the first time in designing I2C > communication with cmos sensor module.I have completed the design. The > post map simulation worked fine and synthesized without warnings and > errors. But when I implemented the design in Spartan 3A DSP by using > pull up resistors for the pins I couldnot get the output.Suggest me > about using the "inout" pins. You can either use tristate pins, fairly easy in verilog and I believe also in VHDL. You can also use open drain, which is implemented as a tristate output with the output value permanently 1'b0 and the enable to activate the current sink. Also, many FPGAs have built-in pull-ups that can be enabled. -- glenArticle: 138943
On Sun, 15 Mar 2009 12:31:01 -0700 (PDT), rickman wrote: [...] >If that thread has not been posted I may well have forgotten >the technique [...] Somehow I suspect that you would have worked it all out for yourself, postings or no postings. But your point is well made. I'm often astonished at the way information picked up long ago turns out to be useful in unexpected contexts (I guess that's called "experience"); and a little memory-jogger is usually needed to bring it all back (I guess that's called "forgetfulness"). -- 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: 138944
Hi all! It might pay with a visit to Orange Tree Technologies (http:// www.orangetreetech.com). We used their ZESTSC2 as a reference design for a system very similar to yours, and designed our own board with a XC3V1400A instead of the original XC3V2000. We had a hitch with the configuration and the guys at Orange Tree where very helpful in finding the problem, (which actually turned out to be a bug in the throtteling of the configuration clock in the Spartan3A). Only hours after they pointed the bug out to Xilinx, a new data sheet was published on their website. Xilinx went the "Synopsys" way and treated it as a feature, not a bug, but Orange Tree where able to provide us with a software workaround in about a day. Very impressive. /Lars P.S. Remove the obvious if you want to mail me directly. D.S.Article: 138945
Lars wrote: > Xilinx went the "Synopsys" way and treated it as a feature, not > a bug, Way off topic. Long before both Xilinx and Synopsys, in a computer game called "advent", short for adventure, as file names were restricted by the operating system to six characters. Back in the 1970s, to be somewhat more precise. In the game, if you explore the cave, you will get to the tomb of the unknown implementer, where a hollow voice is saying: "It's not a bug, it's a feature".Article: 138946
Some useful things linked on our website http://www.enterpoint.co.uk/techitips/techitips.html. As to boards we have lots but maybe Drigmorn1 http://www.enterpoint.co.uk/component_replacements/drigmorn1.html would be a good starting place. John Adair Enterpoint Ltd. On 14 Mar, 19:41, Samuel Thomas Kerr <stk...@cs.purdue.edu> wrote: > I'd like to design a custom microprocessor (just for learning purposes). I > used Lattice's GAL chips with ABEL before, but quickly ran out of space. > As such, I'd like to move over to an FPGA platform. > > However, I've never used FPGAs, VHDL, or Verilog before. > > I was wondering if someone could point me in the right direction? As far a > development board to start with or a book on a programming language, or > both? > > Thanks!Article: 138947
Hi, I am using the Xilinx Spartan 3E starter kit for driving the RFM12B RF transceiver module. I need to have an SPI controller core that can drive this module in SPI mode. The VHDL code that I wrote is totally okay in simulations but its not working through the FPGA board. Can anyone help me with it? I am not being able to debug this thing. The simulation's all well but the RF module is not transmitting any data and I have no idea how to debug it in FPGA hardware.Article: 138948
On Mar 16, 5:20=A0pm, John Adair <g...@enterpoint.co.uk> wrote: > Some useful things linked on our websitehttp://www.enterpoint.co.uk/techi= tips/techitips.html. > > As to boards we have lots but maybe Drigmorn1http://www.enterpoint.co.uk/= component_replacements/drigmorn1.html > would be a good starting place. > > John Adair > Enterpoint Ltd. > > On 14 Mar, 19:41, Samuel Thomas Kerr <stk...@cs.purdue.edu> wrote: > > > I'd like to design a custom microprocessor (just for learning purposes)= . I > > used Lattice's GAL chips with ABEL before, but quickly ran out of space= . > > As such, I'd like to move over to an FPGA platform. > > > However, I've never used FPGAs, VHDL, or Verilog before. > > > I was wondering if someone could point me in the right direction? As fa= r a > > development board to start with or a book on a programming language, or > > both? > > > Thanks! I was so curious... ....to checkout if John's post has some info besides advertizement inside. AnttiArticle: 138949
On 26 Feb., 23:02, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > gabor wrote: > > (snip) > > > For Spartan 3 MIG, which is primitive compared to the Virtex 5 > > MIG, the order of row vs. bank addressing is not important. > > This is due to the fact that the MIG code only leaves one > > row of one bank active at any time. =A0The column address should > > be your low order address bits for linear addressing. =A0This > > will prevent unnecessary row precharge / activate sequences > > when performing linear access to memory. > > One that I might try is a video display that also refreshes > the RAM. =A0That is an old trick that might still work. > > > Also note that > > the least significant bits of the column address are > > incremented inside the memory chip during a burst operation. > > There is no carry out to the upper address bits, so when > > starting a burst you should normally begin at a burst > > boundary to avoid rapping back to previous addresses. > > I don't expect any burst operations. =A0My first system will > be 8080 based, and I don't believe that the 8080 does bursts. > > > Be careful when using the MIG top level interface with > > "linear" address. =A0It may be using the least significant > > bits for the bank address (depends on which interface > > typeDDR, DDR2, etc.). > > -- glen Hi guys, Going further with the thread, I want to "report" that it seems to be working, but partially. In simulation everything goes fine, both for writing and reading data. I generate a sequence of numbers, fill the memory with it, and then read all the positions back, comparing with the sequence of numbers written. If an error is found, a counter is incremented. At the end of the read sequence, if everything goes fine, one led should glow, if not (even a single mismatch was found, which means the error counter is different to zero) then 6 leds glow. I am testing my stuff on an S3E Kit. If I just run the test for a very few rows (say 3), then most of the times the test passes, others it does not. If I run for higher number of rows, then at all times it fails. So, it seems to me that I am getting timing problems. Besides, I have to add that I am not using an external 133 MHz clock to SMA connector, I am using the onboard 50Mhz clock instead and a couple DCMs, one for generating a 100 MHz clock and another one to generate the 90 degree phase shifted clock. Reviewing the implementation reports (ISE 10.1 and ISE 9.2), I see that the signal rst_dqs_div does not meet timing (MAX_DELAY 460 ps). Looking into the details of the UCF, I see that this signal, which for the S3E Starter kit is implemented as a loopback, has an assigment to pin P13. I suppose that that is needed because of packaging to IOBs, which is one of the project options for the MIG generated project. Is there a way to make the signal always internal and not look for a physical pin? The only way I have found to meet timing constraints was to remove that constraint in the UCF (the one that assigns rst_dqs_div signal to pin P13), but now another problem arises: when generating the bitstream, it fails because DRC is not passed, saying that the signal rst_dqs_div was assigned to bank3 which uses impedance controlled buffers or has Vref requeriments, which rst_dqs_div does not meet. How can it be got to work reliably? Even the original project generated by MIG (ver 2.1, ver 2.3) for the S3E Kit, without modifications, fails to meet the timing constraints for signal rst_dqs_div, which is supposed to be a critical timing signal necessary to get the controller working correctly. All your comments and suggestion are very welcome. Kind regards.
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