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
Jim Granville wrote:
> That's a lot of ground to make up. Is the 'fat' in any one area ?
> Does the 797LE version have BCD and Interrupts ?
Looks like it has interrupts, but no BCD.
> Err, why not use/improve the T65 work ?
It's more fun to implement it myself :-)
I've started a new version, see below. Now it is more clean VHDL code and
it should need very few LEs, but a ROM of maybe 1 kbyte. Every microcode is
executed in one clock cycle. I plan to implement a call/return microcode,
with a callstack size of 1 address, too, for helping to reduce the ROM size
(e.g. most addressing modes can be implemented in subroutines). For writing
the microcode program and creating the MIF file, I'll write a Lisp program
again.
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use work.ALL;
entity t_rex_test is
port(
clock_50mhz: in std_logic;
led: out unsigned(7 downto 0);
button: in unsigned(3 downto 0);
dip_switch: in unsigned(3 downto 0);
neg_reset: in std_logic);
end entity t_rex_test;
architecture rtl of t_rex_test is
-- bit position in microcode for indicating the last
-- microcode command in a program
constant mcode_stop_bit : integer:= 7;
-- type for CPU addresses
subtype address_type is std_logic_vector(15 downto 0);
-- type for CPU data words
subtype data_type is std_logic_vector(7 downto 0);
-- microcode commands
constant mcode_load_pc : data_type := x"01";
constant mcode_store_address : data_type := x"02";
-- CPU RAM signals
signal address : address_type;
signal data : data_type;
signal q : data_type;
signal wren : std_logic := '0';
-- microcode ROM signals
signal mcode_address : std_logic_vector(8 downto 0);
signal mcode_q : data_type;
signal mcode_code : data_type;
signal mcode_stop : boolean;
-- scratch register
signal working : address_type := x"0200";
-- current command
signal command : data_type;
-- CPU registers
signal pc : address_type := x"0200";
signal sp : address_type := x"01ff";
signal accu : data_type;
signal x : data_type;
signal y : data_type;
signal z_flag : std_logic;
signal n_flag : std_logic;
signal c_flag : std_logic;
signal v_flag : std_logic;
signal i_flag : std_logic;
signal d_flag : std_logic;
-- CPU statemachine
type cpu_state_type is (
read_command_state,
wait_for_read_state,
read_memory_state,
wait_for_mcode_index,
read_mcode_index,
execute_mcode,
read_mcode
);
signal cpu_state : cpu_state_type := read_command_state;
begin
-- CPU RAM
instance_ram: entity ram
port map (
address => address(11 downto 0),
clock => clock_50mhz,
data => data,
wren => wren,
q => q
);
-- microcode ROM
instance_microcode: entity microcode
port map (
address => mcode_address,
clock => clock_50mhz,
data => x"00",
wren => '0',
q => mcode_q
);
-- read command and execute microcode
process(clock_50mhz, neg_reset)
begin
if neg_reset = '1' then
pc <= x"0200";
sp <= x"01ff";
accu <= x"00";
x <= x"00";
y <= x"00";
z_flag <= '0';
n_flag <= '0';
elsif rising_edge(clock_50mhz) then
case cpu_state is
-- read next command
when read_command_state =>
address <= pc;
cpu_state <= wait_for_read_state;
when wait_for_read_state =>
cpu_state <= read_memory_state;
-- use command as index in first 256 ROM bytes
when read_memory_state =>
pc <= pc + 1;
mcode_address <= '0' & q;
cpu_state <= wait_for_mcode_index;
when wait_for_mcode_index =>
cpu_state <= read_mcode_index;
-- microcode program starts at index + 256
when read_mcode_index =>
mcode_address <= '1' & mcode_q;
cpu_state <= execute_mcode;
when execute_mcode =>
mcode_address <= mcode_address + 1;
cpu_state <= read_mcode;
-- execute microcode program
when read_mcode =>
mcode_address <= mcode_address + 1;
case mcode_code is
-- copy pc to working register
when mcode_load_pc =>
working <= pc;
-- store working register to RAM address register
when mcode_store_address =>
address <= working;
-- unknown microcommand, read next command
when others =>
cpu_state <= read_command_state;
end case;
-- if mcode_stop_bit was set, read next command
if mcode_stop then
cpu_state <= read_command_state;
end if;
end case;
end if;
end process;
mcode_code <= mcode_q and "01111111";
mcode_stop <= true when mcode_q(mcode_stop_bit) = '1' else false;
end architecture rtl;
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Article: 119826Well, try it out! That's the beauty with FPGAs: unlimited expermentation for free! Peter On May 26, 4:53 pm, Test01 <cpan...@amd.com> wrote: > I like your trick but I am trying to understand how to express that in verilog. > > Currenlty my verilog output is > > signal_out = (test_sig ? 1'bz : 1'b0); > > where signal_out is an open drain output and test_sig is the signal from the FPGA fabric that I need to pass to the outside world. > > Here is my attempt at modifying the verilog to try your suggestion: > > signal_inout = (test_sig ? (signal_inout ? 1'bz : 1'b1) : 1'b0); > > With the above modification, signal_inout will be a bidirectional pin if not detected high by the fpga i/o and at that time the upper transistor is turned off. > > I would like to confirm that this is what you are suggesting. > > Thanks for your valuable input. > > This may help me out here. Please let me know.Article: 119827
Frank Buss wrote: > Jim Granville wrote: > > >>That's a lot of ground to make up. Is the 'fat' in any one area ? >>Does the 797LE version have BCD and Interrupts ? > > > Looks like it has interrupts, but no BCD. > > >>Err, why not use/improve the T65 work ? > > > It's more fun to implement it myself :-) OK. > I've started a new version, see below. Now it is more clean VHDL code and > it should need very few LEs, but a ROM of maybe 1 kbyte. Every microcode is > executed in one clock cycle. ROM makes sense, pretty much every FPGA these days have these for free, and they should be use more in Soft CPU designs. > I plan to implement a call/return microcode, > with a callstack size of 1 address, too, for helping to reduce the ROM size > (e.g. most addressing modes can be implemented in subroutines). For writing > the microcode program and creating the MIF file, I'll write a Lisp program > again. Let us know how the different approach impacts LE count. -jgArticle: 119828
On Sat, 26 May 2007 14:25:55 -0700, Test01 <cpandya@yahoo.com> wrote:
>Thanks for your valuable input.
>
>You asked why open drain output:
>
>I need to generate 1.8V output for the receiver. The Spartan3 FPGA vcco pins on my board are tied to 3.3V. Driving push-pull will generate 3.3V but I needed 1.8V output.
>
>I am sorry I am a beginner in this. Can you explain how you derived 150 pf capacitance?
120. But that's was one of those reducto ad absurdum things, just to
demonstrate that something is goofy somewhere.
>
>Thanks again.
Do this:
|<----- 60 ohm trace ----->|
fpga---40r-----------------------------+---your
out | gadget
|
60r
|
|
|
gnd
or, to save some power, you could source terminate...
|<----- 60 ohm trace ----->|
fpga--100r---+----------------------------your
out | gadget
|
150r
|
|
|
gnd
Either way, you get close to 1.8 volts.
John
Article: 119829Subject says it all - would like to hear from people using the SUZAKU modules, how well they work, what toolchain / development hardware you use, etc. http://www.atmark-techno.com/en/products/suzaku Especially interested in learning what the workflow is for iterating on a design that has an embedded MicroBlaze, does the inclusion of the soft-core CPU add a lot of turnaround time during recompilation of a design into a bitstream? Or is that part mostly static and unlikely to slow down debugging & iteration. And any pointers to appropriate JTAG interfaces for USB2 or Ethernet would be appreciated too. Rob -- Posted via a free Usenet account from http://www.teranews.comArticle: 119830
I like Peter's suggestion so I was going to try that first. But to respond to your question - here is a termination topology for this particular signal on my board 1.8V _ | |150Ohm Pull FPGA LVCMOS33 | Up Resistor Open Drain Driver ---+--100Ohm-->Rx 60 Ohm Trace. Thanks for your inputArticle: 119831
What is the best way to move paralell bits of data over two clock domains inside an xilinx FPGA (Spartan-3E) to avoid meta stability? By paralell bits i mean for example 10 x 16 bits of data collected from 10 16-bit AD converters in one clock domain which have to be moved to en different clock domain (of higher frequency). What about dual port RAM, are they safe? Or should i clock all data individually through two d-flipflops in series which are clocked by the second clock?Article: 119832
Hello, That is actually possible and I've tried it with... some result! I have a Spartan-3 Starter Kit (not the 3E though..). It also comes with the minimum 8-color VGA-output that felt abit on the low-side. As a fun project I tried out doing this kind of mix/dither. I started out with a 640*480*60Hz(25Mhz pixelclock)@3-bit color and ended somewhere in the region of having either a x-resolution at 4000 pixels + (4000*480) or approx 4000+ colors. The pixel clock was set to the DCM max and below (200-280Mhz) The output did however (as someone already mentioned) ONLY work with old CRT-screens but did the job quite god. Probably you could do some filtering on it (maybe simple RC-filter) and make it work better with TFT also. I've been told that the simple R2R-ladder also has it limitations somewhere at 12-15 bits area so this could be a nice try- out project that is left to do.. For home-demo purposes it was a quite nice test, for real stuff a no- no! The version I did was only doing dithering in the x-res and by doing it both ways the result would of course be even better.. The worst problem for me was blinking due to timing problems @ 250+ but that could probably also be removed. OK I'll just have to purpose a demo-scene for FPGA's again... anyone? Minimum hardware and maximum results of course. I think some fantastic things could be done that even would have the potential to beat the classic computer-based Demo-scenes.. Of course both a binary-release for download and a movie for everyone to watch. As I first suggestion for something like that I'll put to get I just ordered a simple extender-board for my Spartan-3 Starter Kit. Its my own PCB and includes: 12-bit VGA, Line-Out Sound, Joystick- port, MIDI-In, SD-Card-connector, PS2-connector. When I get it to work I have 9 extras for sale. It has been ordered from a proffesional PCB- manufacturer so I have high expectations for it! If anyone is interested I've got 8 unpopulated PCB left. One for me and one for a friend! /Magnus On May 25, 10:49 am, "Symon" <symon_bre...@hotmail.com> wrote: > "Mark McDougall" <m...@vl.com.au> wrote in message > > news:465659ec$0$17960$5a62ac22@per-qv1-newsreader-01.iinet.net.au... > > > checo wrote: > > >> I own a Spartan 3E Starter Kit, which I plan to use for crowd- > >> entertainment purposes. Since the 3-bit VGA output is way too limiting > >> for my project, I am planning to add a 12-bit VGA port to my Starter > >> Kit. > > > Since MikeJ must be napping... ;) > > > <http://home.freeuk.com/fpgaarcade/displaytest.htm> > > > Regards, > > > -- > > Mark McDougall, Engineer > > Hi Guys, > I wonder if you could improve the colour depth by just increasing the dot > rate. So, instead of just on or off for each pixel, you could have 0, 1/2, > 1. Probably good enough for "crowd entertainment"? > Cheers, Syms.Article: 119833
"Daf" <Daf@daf.net> wrote in message news:46599ed5$0$90262$14726298@news.sunsite.dk... > What is the best way to move paralell bits of data over two clock domains > inside an xilinx FPGA (Spartan-3E) to avoid meta stability? > > By paralell bits i mean for example 10 x 16 bits of data collected from 10 > 16-bit AD converters in one clock domain which have to be moved to en > different clock domain (of higher frequency). > > What about dual port RAM, are they safe? Yes, make a FIFO. This is the standard way to do it. Use the Coregen Wizard. > Or should i clock all data individually through two d-flipflops in series > which are clocked by the second clock? No, that won't work. Each bit will have a slightly different setup time, because no two path delays will be equal. You'll get bits from word [n-1] mixed with bits from word [n].Article: 119834
Nice work Frank! I haven't looked in detail at your work, but the general idea of doing nostalgic implementations, doing it for fun and doing it in a minimum resource-fashion is my cup of tea. Just one suggestion that is something that I'm on right now (or... one of the things I'm on right now). If you are willing to sacrifice ALOT FMAX to save FPGA-resources maybe an inner CPU with a very simple instructions-set could do? By doing this and building the instruction-set in reusuable pieces I think there are potential for resource-gains to earn. But if you remember the speed these hogs were doing in the wild days (1,2,4,8 Mhz) maybe similar preformance is still OK. OK, you won't win prices in minimum-power-usage, in readability or probably in anything but I have a hunch this is the way to achieve MAXIMUM usage of resources. Me, myself have been working on implementing a minimum 68K-core this way. Still alot of work left todo, but the current reading of 8% of a Spartan3-200K is quite nice.. My goal is to, at least, get something working in about 20% of a Spartan3-200K. /Magnus On May 27, 7:20 am, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Frank Buss wrote: > > Jim Granville wrote: > > >>That's a lot of ground to make up. Is the 'fat' in any one area ? > >>Does the 797LE version have BCD and Interrupts ? > > > Looks like it has interrupts, but no BCD. > > >>Err, why not use/improve the T65 work ? > > > It's more fun to implement it myself :-) > > OK. > > > I've started a new version, see below. Now it is more clean VHDL code and > > it should need very few LEs, but a ROM of maybe 1 kbyte. Every microcode is > > executed in one clock cycle. > > ROM makes sense, pretty much every FPGA these days have these for free, > and they should be use more in Soft CPU designs. > > > I plan to implement a call/return microcode, > > with a callstack size of 1 address, too, for helping to reduce the ROM size > > (e.g. most addressing modes can be implemented in subroutines). For writing > > the microcode program and creating the MIF file, I'll write a Lisp program > > again. > > Let us know how the different approach impacts LE count. > > -jgArticle: 119835
not napping and not in China for a change, just busy enjoying the sunshine here :) "Mark McDougall" <markm@vl.com.au> wrote in message news:465659ec$0$17960$5a62ac22@per-qv1-newsreader-01.iinet.net.au... > checo wrote: > >> I own a Spartan 3E Starter Kit, which I plan to use for crowd- >> entertainment purposes. Since the 3-bit VGA output is way too limiting >> for my project, I am planning to add a 12-bit VGA port to my Starter >> Kit. > > Since MikeJ must be napping... ;) > > <http://home.freeuk.com/fpgaarcade/displaytest.htm> > > Regards, > > -- > Mark McDougall, Engineer > Virtual Logic Pty Ltd, <http://www.vl.com.au> > 21-25 King St, Rockdale, 2216 > Ph: +612-9599-3255 Fax: +612-9599-3266Article: 119836
spartan3wiz wrote:
> If you are willing to sacrifice ALOT FMAX to save FPGA-resources
> maybe an inner CPU with a very simple instructions-set could do?
Yes, this was my idea. I have enhanced my FPGA implementation to a
Forth-like CPU, this is the current version:
http://www.frank-buss.de/vhdl/t_rex_test2.vhdl
It has the following microcodes:
call
load-pc
load-address
load-q
load-accu
load-x
load-y
store-pc
store-address
store-data
store-accu
store-x
store-y
inc
dec
add
lshift-8
or
nop
The load and store commands loads and stores from the specified register to
an internal stack (stack size is configurable). "call" executes a program
at the location specified in the next byte. A return is implemented, if bit
7 is set in the microcode. The rest are instructions needed to make it
simpler to implement the 6502 instruction set, e.g. "or" pops the first two
values from stack, does a binary OR and pushs the result back to stack.
Testing the microcodes with a simulator is too time consuming, so I've
implemented an emulator in Lisp, which creates the opcode ROM, too and the
constant list for the microcodes for pasting into the VHDL code:
http://www.frank-buss.de/vhdl/cpu2.lisp
Playing with it is really nice, e.g. this is the output of an interactive
session:
CL-USER > (dump #x1f00)
1F00: 00 00 00 00 00 00 00 00
NIL
CL-USER > (execute-command)
current registers:
a: 00, x: 00, y: 00
pc: 0200, mcode-address: 0000,
executing microcode: CALL
a: 00, x: 00, y: 00
pc: 0201, mcode-address: 0119,
executing microcode: LOAD-PC
a: 00, x: 00, y: 00
pc: 0201, mcode-address: 011A,
executing microcode: STORE-ADDRESS
a: 00, x: 00, y: 00
pc: 0201, mcode-address: 011B,
executing microcode: LOAD-PC
a: 00, x: 00, y: 00
pc: 0201, mcode-address: 011C,
executing microcode: INC
a: 00, x: 00, y: 00
pc: 0201, mcode-address: 011D,
executing microcode: STORE-PC
a: 00, x: 00, y: 00
pc: 0202, mcode-address: 011E,
executing microcode: LOAD-Q
a: 00, x: 00, y: 00
pc: 0202, mcode-address: 012B,
executing microcode: STORE-ACCU
a: 2A, x: 00, y: 00
pc: 0202, mcode-address: 012C,
NIL
CL-USER > (execute-command)
current registers:
a: 2A, x: 00, y: 00
pc: 0202, mcode-address: 012C,
executing microcode: CALL
a: 2A, x: 00, y: 00
pc: 0203, mcode-address: 010C,
executing microcode: CALL
a: 2A, x: 00, y: 00
pc: 0203, mcode-address: 0106,
...
NIL
CL-USER > (dump #x1f00)
1F00: 2A 00 00 00 00 00 00 00
NIL
This was the executing of the following small program, compiled with cc65:
.org $200
lda #42
sta $1f00
Now I can implement and test the rest very fast, because I can add
debugging output very easily, implement all addressing modes of one
instruction with a higher-level instruction to avoid (Lisp) code
duplication etc.
On the FPGA side I have to simulate the microcodes, only. If every
microcode does what it should do, then all microcode programs should work
immediatly, because they were tested with my Lisp prorgam before.
> OK, you won't win prices in minimum-power-usage, in readability or
> probably in anything but I have a hunch this is the way to achieve
> MAXIMUM usage of resources.
I think readability is very good (ok, maybe because I know Forth and Lisp)
and power-usage should be good, too, because fewer LEs are used. My current
Forth FPGA implementation needs 319 LEs (about 5% of the small Cyclone
EP1C6Q240C8). But I expect 10 times slower than e.g. the T65, so the all in
all cycles per power would be not so good.
> Me, myself have been working on
> implementing a minimum 68K-core this way. Still alot of work left
> todo, but the current reading of 8% of a Spartan3-200K is quite nice..
> My goal is to, at least, get something working in about 20% of a
> Spartan3-200K.
Nice. How does your microcode looks like? Some instructions are very
similar to the 6502, so maybe we can develop the perfect microcode for both
:-)
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Article: 119837Have a look at myTechXclusives article of 2001 on crossing asynchronous clock domains. http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&category=-19240&sGlobalNavPick=SUPPORT&sSecondaryNavPick=&multPartNum=1&sTechX_ID=pa_clock_bound Sorry for the insanely long URL. You do not need a FIFO (which would work fine) if, as you say, the receiving clock is faster than the sending clock. But you must have a reasonably delayed "READY" signal that indicates valid data. Then you just need a control handshake with the faster receive clock domain. Peter Alfke On May 27, 8:38 am, "Andrew Holme" <and...@nospam.com> wrote: > "Daf" <D...@daf.net> wrote in message > > news:46599ed5$0$90262$14726298@news.sunsite.dk... > > > What is the best way to move paralell bits of data over two clock domains > > inside an xilinx FPGA (Spartan-3E) to avoid meta stability? > > > By paralell bits i mean for example 10 x 16 bits of data collected from 10 > > 16-bit AD converters in one clock domain which have to be moved to en > > different clock domain (of higher frequency). > > > What about dual port RAM, are they safe? > > Yes, make a FIFO. This is the standard way to do it. Use the Coregen > Wizard. > > > Or should i clock all data individually through two d-flipflops in series > > which are clocked by the second clock? > > No, that won't work. Each bit will have a slightly different setup time, > because no two path delays will be equal. You'll get bits from word [n-1] > mixed with bits from word [n].Article: 119838
I have one more question on Peter's suggestion. As per my understanding, there will be finite amount of propagatoin delay for the external signal to get back into the Spartan3 FPGA fabric - may be 5 ns? By then the top transistor may have driven the signal to 3.3V? Is that possible? Well, if the slew rate is 0.1v/ns then it will be 0.5v in 5 ns? But I am assuming that the slew rate will be better by using the top transistor of the fpga and hence better of chance of getting to 3.3V output quicker. I am using XC3S400FG456C-4 device. Please let me know.Article: 119839
Frank Buss <fb@frank-buss.de> writes:
> I've implemented a first version of a 6502 core. It has a very simple
> architecture: First the command is read and then for every command a list
> of microcodes are executed, controlled by a state machine. To avoid the
> redundant VHDL typing, the VHDL code is generated with a Lisp program:
>
[...]
>
> Any ideas how to improve the Lisp code? I like my idea of using a lambda
> function in addressing-commands, because this looks more clean than a
> macro, which I've tried first, but I don't like the explicit call of
> emit-lines. How can I refactor it to a more DSL like approach?
(Followup was set to comp.arch.fpga, but since this is Lisp-related,
I've changed followup to c.l.l.)
It seems to me that a more natural way to represent this code in a
Lisp program would be to use some form of syntax trees.
For example, the VHDL statement
if q = x"00" then z_flag <= '1'; else z_flag <= '0'; end if;
could be represented with this tree:
(if (= q #x00)
(<= z_flag #\1)
(<= z_flag #\0))
Producing VHDL code from the tree representation should be
straight-forward.
Peter Seibel's book has a chapter on HTML-generation which might be
helpful. You might also want to look up "abstract syntax" or "syntax
trees" in any compiler textbook.
Sven-Olof Nystr|m
Article: 119840Ahh nice! I think we have connected brains! :-) Actually my idea isn't that refined yet. I am doing the long-way- around the problem. After seeing some of the different retro-cores out there (6502, 8051,Z80 and 68K) that I think took just too much resource off my poor small FPGA, I decided that it must be possible to implement something smaller and still have full functionality. The people who have implemented these cores straight in VHDL/Verilog are fantastic people way over my current limit I think, so all cheers to you! If I/we don't need the 50MHz (or so) that can be achieved in today's standard hobby FPGA-development-cards, maybe the FMAX CAN be, in some way, converted into reused blocks. I started my 68K-project by using the fantastic, already super- optimized Picoblaze of Ken Chapman that are Xilinx-specific and SMALL: http://en.wikipedia.org/wiki/PicoBlaze http://www.xilinx.com/ipcenter/processor_central/picoblaze/picoblaze_user_resources.htm By shifting over to, for example the Pacoblaze: http://bleyer.org/pacoblaze/ I can then make it run on anything and still be quite small! My work is only half-way finished and I'm not sure It'll fit into the tight program-space, but by taking on hard projects at least you learn something I think. To fit this into the program space of the Picoblaze I need to do MAXIMUM reuse of the assembler code, thus crystallizing out the nice reusable parts into assembler sub-routines. Maybe even finding reuse in places where it otherwise might be missed.. By using an 8-bit CPU to emulate an 16-bit CPU I can save resources but get a hard performance-hit. It is very time-consuming doing these tests and there are lots of stuff left to fix, for example the memory access problem, but I'm keep trying until... well until I don't feel like it! :-) Then when I'm finished (and have something working), I have several next step possibilities of which I would like to try all. 1) Just keep the slow small core making sure it run on Picoblaze (xilinx hardware) as well as Pacoblaze (anything..) and does its job. 2) Try removing all unused instructions from the 8-bit CPU's instruction set, thus making it even smaller BUT destroying the possible future upgrades and removing the compatibility of the internal parts (this would only be pubhished as already compiled BIT- files I think..) 3) Try adding extra instructions (from implementing the assembler sub- routines into new instructions) by looking at profiling of solution 1) running. By doing this we can find the perfect balance (or several balances) between size/speed depending on the demands on the goal circuit usage. 4) A combination of 2) and 3) 5) Maybe building something completely new out of the things learned from all the above.. But your thoughts on doing something generic just sounds NICE! A nice tool that kept me going this far is: http://www.mediatronix.com/pBlazeIDE.htm /Magnus On 27 Maj, 19:36, Frank Buss <f...@frank-buss.de> wrote: > spartan3wiz wrote: > > If you are willing to sacrifice ALOT FMAX to save FPGA-resources > > maybe an inner CPU with a very simple instructions-set could do? > > Yes, this was my idea. I have enhanced my FPGA implementation to a > Forth-like CPU, this is the current version: > > http://www.frank-buss.de/vhdl/t_rex_test2.vhdl > > It has the following microcodes: > > call > load-pc > load-address > load-q > load-accu > load-x > load-y > store-pc > store-address > store-data > store-accu > store-x > store-y > inc > dec > add > lshift-8 > or > nop > > The load and store commands loads and stores from the specified register to > an internal stack (stack size is configurable). "call" executes a program > at the location specified in the next byte. A return is implemented, if bit > 7 is set in the microcode. The rest are instructions needed to make it > simpler to implement the 6502 instruction set, e.g. "or" pops the first two > values from stack, does a binary OR and pushs the result back to stack. > > Testing the microcodes with a simulator is too time consuming, so I've > implemented an emulator in Lisp, which creates the opcode ROM, too and the > constant list for the microcodes for pasting into the VHDL code: > > http://www.frank-buss.de/vhdl/cpu2.lisp > > Playing with it is really nice, e.g. this is the output of an interactive > session: > > CL-USER > (dump #x1f00) > > 1F00: 00 00 00 00 00 00 00 00 > NIL > > CL-USER > (execute-command) > current registers: > a: 00, x: 00, y: 00 > pc: 0200, mcode-address: 0000, > > executing microcode: CALL > a: 00, x: 00, y: 00 > pc: 0201, mcode-address: 0119, > > executing microcode: LOAD-PC > a: 00, x: 00, y: 00 > pc: 0201, mcode-address: 011A, > > executing microcode: STORE-ADDRESS > a: 00, x: 00, y: 00 > pc: 0201, mcode-address: 011B, > > executing microcode: LOAD-PC > a: 00, x: 00, y: 00 > pc: 0201, mcode-address: 011C, > > executing microcode: INC > a: 00, x: 00, y: 00 > pc: 0201, mcode-address: 011D, > > executing microcode: STORE-PC > a: 00, x: 00, y: 00 > pc: 0202, mcode-address: 011E, > > executing microcode: LOAD-Q > a: 00, x: 00, y: 00 > pc: 0202, mcode-address: 012B, > > executing microcode: STORE-ACCU > a: 2A, x: 00, y: 00 > pc: 0202, mcode-address: 012C, > > NIL > > CL-USER > (execute-command) > current registers: > a: 2A, x: 00, y: 00 > pc: 0202, mcode-address: 012C, > > executing microcode: CALL > a: 2A, x: 00, y: 00 > pc: 0203, mcode-address: 010C, > > executing microcode: CALL > a: 2A, x: 00, y: 00 > pc: 0203, mcode-address: 0106, > > ... > > NIL > > CL-USER > (dump #x1f00) > > 1F00: 2A 00 00 00 00 00 00 00 > NIL > > This was the executing of the following small program, compiled with cc65: > > .org $200 > lda #42 > sta $1f00 > > Now I can implement and test the rest very fast, because I can add > debugging output very easily, implement all addressing modes of one > instruction with a higher-level instruction to avoid (Lisp) code > duplication etc. > > On the FPGA side I have to simulate the microcodes, only. If every > microcode does what it should do, then all microcode programs should work > immediatly, because they were tested with my Lisp prorgam before. > > > OK, you won't win prices in minimum-power-usage, in readability or > > probably in anything but I have a hunch this is the way to achieve > > MAXIMUM usage of resources. > > I think readability is very good (ok, maybe because I know Forth and Lisp) > and power-usage should be good, too, because fewer LEs are used. My current > Forth FPGA implementation needs 319 LEs (about 5% of the small Cyclone > EP1C6Q240C8). But I expect 10 times slower than e.g. the T65, so the all in > all cycles per power would be not so good. > > > Me, myself have been working on > > implementing a minimum 68K-core this way. Still alot of work left > > todo, but the current reading of 8% of a Spartan3-200K is quite nice.. > > My goal is to, at least, get something working in about 20% of a > > Spartan3-200K. > > Nice. How does your microcode looks like? Some instructions are very > similar to the 6502, so maybe we can develop the perfect microcode for both > :-) > > -- > Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.deArticle: 119841
Frank Buss wrote: <snip> > > On the FPGA side I have to simulate the microcodes, only. If every > microcode does what it should do, then all microcode programs should work > immediatly, because they were tested with my Lisp prorgam before. Just checking if you have seen the work of Jan Decaluwe ? http://myhdl.jandecaluwe.com/doku.php/start > >>OK, you won't win prices in minimum-power-usage, in readability or >>probably in anything but I have a hunch this is the way to achieve >>MAXIMUM usage of resources. > > > I think readability is very good (ok, maybe because I know Forth and Lisp) > and power-usage should be good, too, because fewer LEs are used. My current > Forth FPGA implementation needs 319 LEs (about 5% of the small Cyclone > EP1C6Q240C8). But I expect 10 times slower than e.g. the T65, so the all in > all cycles per power would be not so good. If this runs slower, one of my pet ideas for FPGA cores, is to design them to run from SerialFLASH memory. Top end ones (winbond) run at 150MBd of link speed, so can feed nearly 20MB/s of streaming code. Ideally, the core has a short-skip opcode, as the jump in such memory has a higher cost. -jgArticle: 119842
On Sun, 27 May 2007 06:21:42 -0700, Test01 <cpandya@yahoo.com> wrote: >I like Peter's suggestion so I was going to try that first. But to respond to your question - here is a termination topology for this particular signal on my board > >1.8V _ | |150Ohm Pull FPGA LVCMOS33 | Up Resistor Open Drain Driver ---+--100Ohm-->Rx What does that mean? > >60 Ohm Trace. > >Thanks for your input Why open drain? That screws up the impedance match and changes the slews, since the rise and fall must have different impedances. JohnArticle: 119843
From fpga open driver to 150 ohm pull-up and then to 100 Ohm series termination close to the receiver. I used open drain is because I needed to generate 1.8V output. Can you please also respond my question about Peter's suggestion of using the top transitior until it reaches high threshold of 1.5V? My concern here is that the fpga fabric will have fair amount of prop delay before it turns off the top fpga transistor.Article: 119844
Hi Antti, I have successfully implemented CoreABC on my ProASIC3, Fusion and CoreMP7 board. If you have any questions just ask. Kind regards, Vince http://mobile.skynetblogs.be On 20 apr, 11:13, Antti <Antti.Luk...@xilant.com> wrote: > Hi > > new version ofactelcoreconsole includes CoreABC - a tiny Fpga > SoftCore with APB interface for peripherals, but I have trouble > creating a SoC, i wonder if any one has worked it out ? > > hm.. eh, I tried to connect Fusion on chip used Flash blocks to ABC, > maybe this is not supported and was the reason for problem. Still if > anyone has experience with ABC, would be nice to hear:) > > AnttiArticle: 119845
On Sun, 27 May 2007 13:37:24 -0700, Test01 <cpandya@yahoo.com> wrote: >From fpga open driver to 150 ohm pull-up and then to 100 Ohm series termination close to the receiver. I used open drain is because I needed to generate 1.8V output. > >Can you please also respond my question about Peter's suggestion of using the top transitior until it reaches high threshold of 1.5V? My concern here is that the fpga fabric will have fair amount of prop delay before it turns off the top fpga transistor. It is NOT necessary to use an open drain. It's not even a good idea. So Peter's trick is not needed. JohnArticle: 119846
Thanks, you encouraged me to try that tack again. :-) I commented out the bogus sleep() definition, and I had to drop a "#define LWIP_TIMEVAL_PRIVATE 0" to keep lwip away from struct timeval. Next, to figure out why the Xilinx gdb quit giving me symbols... (yes I have -g -O0 in both the app and libraries...) ken Paul Tobias wrote: > I had a similar problem developing an LWIP raw api program. Commenting > out the definition of sleep() in the EDK source tree fixed it. I also > wondered how the other applications managed to get around this. > > Paul > www.paultobias.com > > "Ken Ryan" <newsryan@leesburg-geeks.org> wrote in message > news:4657B037.1010500@leesburg-geeks.org... >> Hello all! >> >> Has anyone had success using LwIP along with some of the xilkernel >> functions in a system that is based on the PPC and hard Trimode Ethernet >> MAC? >> >> I keep running into a problem where the xtemac driver pulls in some >> xilinx header files that collide with unistd.h (pulled in by e.g. >> pthread.h). > ... > ./ppc405_0/include/sleep.h:32: error: conflicting types for `sleep' > ... >Article: 119847
Does Quartus-II 7.1 support the Systemverilog preprocessor's ``
concatenator?
`define pori_reg(r) \
r <= def_``r
localparam int def_hp_length = 800;
localparam int def_hp_retrace_end = 720;
localparam int def_hp_disp_start = 80;
always @( posedge clk )
if ( !rstn )
begin
`pori_reg( hp_length );
`pori_reg( hp_retrace_end );
`pori_reg( hp_disp_start );
/////////////////////////////////////////////////
// equivalent to
/////////////////////////////////////////////////
always @( posedge clk )
if ( !rstn )
begin
hp_length <= def_hp_length;
hp_retrace_end <= def_hp_retrace_end;
hp_disp_start <= def_hp_disp_start;
This simulates fine in Modelsim XE-III 6.2c Starter Edition, but Quartus
complains:
Error (10108): Verilog HDL Compiler Directive error at vga_reg.sv(42):
missing Compiler Directive
Error (10170): Verilog HDL syntax error at vga_reg.sv(42) near text
"hp_length"; expecting ";"
...
Article: 119848Hello, I created vhdl model of risc processor. During simulation it works correctly, but when I programmed and run it on FPGA Cyclone device, it didn't work. So I applied some signals in SignalTap Analyzer (without changing vhdl code), and it started work properly. I know that problem description is general, but maybe someone can give me some hint, what can be wrong, or what should I look for. Thanks in advice. -- MaciekArticle: 119849
On May 28, 12:18 am, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Sun, 27 May 2007 13:37:24 -0700, Test01 <cpan...@yahoo.com> wrote: > >From fpga open driver to 150 ohm pull-up and then to 100 Ohm series termination close to the receiver. I used open drain is because I needed to generate 1.8V output. > > >Can you please also respond my question about Peter's suggestion of using the top transitior until it reaches high threshold of 1.5V? My concern here is that the fpga fabric will have fair amount of prop delay before it turns off the top fpga transistor. > > It is NOT necessary to use an open drain. It's not even a good idea. > So Peter's trick is not needed. > > John Test01, If the VRP and VRN pins for the bank in question are unused, you might consider adding a couple of resistors to them, changing the buffer to LVDCI_33. Maybe you need a couple in parallel, and changing the "series" 100 ohm resistor located at the receiver to 60 ohms parallel and getting rid of the pull-up. Just a thought in trying to avoid splicing a series source resistor at the FPGA. I think this may be another way of doing what John suggested. -Newman
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