6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Nov 23, 2024 12:02 am

All times are UTC




Post new topic Reply to topic  [ 15 posts ] 
Author Message
PostPosted: Sat Oct 06, 2012 6:57 pm 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
I've been busy learning fpgasm, with some success. I made some almost trivial circuits and decided to see if I can wrap Arlet's 6502 into an fpgasm module. Stacksmith, the creator of fpgasm was kind enough to let me use a pre-release tool, xdlsuck, which basicaly lets you make a hardmacro from anything you can synthesize. So here is what I did:
* Using Verilog, I created a simple circuit with Arlet's core, with all inputs and outputs connected to external pins. In order to keep the clock routed in the fast clock logic, I had to create a clock buffer for the external clock input. I synthesized it using the usual Xilinx tools. Takes a little over a minute.
* Using xdlsuck, I converted it to an fpgasm module. The pins were automatically converted into in and out pins for the module. That took about a second once I had everything figured out.

Once I had the core, I put together a simple fpgasm circuit connecting the core to the outside pins (same ones I used in verilog) for comparison. I ran fpgasm on it and generated an output bitstream.

I compared the original verilog ncd file and the fpgasm ncd file. They seem to be the same, with minor routing differences.

Fpgasm takes about 7 seconds, from source to configured fpga! I am really blown away by this. I changed the core's location and some wiring, sure enough, 7 seconds to make a new one.

I was worried that the "under 10 seconds" only applied to the simple examples. Arle'ts core takes up almost a quarter of XC3S200, so it's a reasonable project.

I haven't had a chance to test the workings of Arlet's 6502 core - it's just connected to FPGA pins right now. I have to rig up a simple test (any suggestions appreciated).

This is only a test, but it looks very promising.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Sat Oct 06, 2012 7:59 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
Interesting!
If you tie off inputs such as interrupts and rdy, and then (preferably resistively) tie the databus to some suitable opcode such as NOP or LDA, you should see the address bus count up at a suitable rate. If there's a sync output that should oscillate at the appropriate rate too. An opcode such as PLA or RTS or RTI will do something more intricate as the instruction fetches will interleave with stack accesses: if you have a logic analyser it should make sense. But even a frequency count on the high-order address pins should be informative.
I think I tried this once using FPGA-internal tie-offs. I'm not sure whether or not I was successful.
Cheers
Ed


Top
 Profile  
Reply with quote  
PostPosted: Sat Oct 06, 2012 8:10 pm 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
Thanks Ed. It sounds like a good way to get started.

I was too tired yesterday to do anything else. I am inclined to connect the core to a Block RAM with an 8-bit output and the buses to the LEDs and run it with a slow clock. I have to find an assembler that will output to a file that I could convert to a memory initialization file... Any thoughts?

Stacksmith's setup is 2 fpga boards - one providing a slow clock and 7-seg displays, second board for the test circuit. He strongly recommends it and I can now see that it is good to keep your test circuit in its own FPGA. I have an old Xula. I don't know if Arlet's core will fit into an XC3S50 though.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Sat Oct 06, 2012 8:19 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
For a small test program you can get a hex dump from http://skilldrick.github.com/easy6502/#first-program


Top
 Profile  
Reply with quote  
PostPosted: Sat Oct 06, 2012 8:33 pm 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
Thanks. I will try it later.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 08, 2012 10:56 pm 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
Got a working 6502.

BRAM feeding Arlet's core - 2K ram connected to 11 bits of address bus. Filled with E9 (nop) and monitored address bus - incremented correctly. Stuck in a jump, worked. I have to get an assembler.

My fpgasm circuit now contains a bram, a bufg for the clock, Arlet's core and a 6-bit debug interface.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2012 12:14 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
enso wrote:
Got a working 6502...

That is good. What is your level of experience? Maybe an introduction is in order if you would like to tell of your experience in electronics? Just a suggestion, not a requirement. It's a great place to "introduce" your initial skill factor IMO...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2012 2:24 am 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
I am a bit rusty with the 6502 (a long time since my C64 and Atari days)... I'll try to put an introduction together in the proper forum. For now you can treat me as a fairly advanced fool.

Any advice on a simple cross-assembler that outputs something I can convert to a BRAM initialization file? fpgasm takes a file that looks like the usual BRAM init string, something like:
...
INIT_00::E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E900084CE9E9E9E9E9E9E9E9
INIT_01::E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9
...
I obviously don't expect any assembler to put that out - I can write a conversion program from a binary or parse a simple text file...

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2012 3:36 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8544
Location: Southern California
If you want NOPs, make it EA. E9 is SBC#. Actually SBC #E9 over and over would work too.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2012 3:50 am 
Offline
User avatar

Joined: Mon Apr 23, 2012 12:28 am
Posts: 760
Location: Huntsville, AL
It's been quite a while since I used the BRAM initialization method that you are using.

In Verilog, (and in VHDL) you can use an initial block in your code which uses the $readmemh() or $readmemb() system functions to open and read ASCII hex/bin files and initialize the rams. You can find an example of this technique here. Backing up in that directory tree, you can find some 65C02 test code examples and utility programs that I wrote to support the use of this technique for testing my 65C02 FPGA core. BigEd and others can provide you links to more complete test programs.

With this block RAM initialization approach, you can edit a test program, assemble it, convert it into $readmemh() compatible format, and then simply restart ISim/Modelsim to reload it. This greatly speeds the testing of the cores.

_________________
Michael A.


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 10, 2012 3:07 am 
Offline

Joined: Sun Nov 08, 2009 1:56 am
Posts: 411
Location: Minnesota
Quote:
Any advice on a simple cross-assembler that outputs something I can convert to a BRAM initialization file? fpgasm takes a file that looks like the usual BRAM init string, something like:
...
INIT_00::E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E900084CE9E9E9E9E9E9E9E9
INIT_01::E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9
...
I obviously don't expect any assembler to put that out - I can write a conversion program from a binary or parse a simple text file...


Mmm...what's the "00084C" in the top line? That looks like a BRK instruction followed by...a JMP to $E9E9? Is that even in your 2K address space? Or do only the low 11 bits count?

Anyway, as far as an assembler goes you can find several here that output Intel or Motorola format hex files (as text). You can easily strip off the address prefix and checksum suffix off each line to get just the data, to which you can add your own prefix (sounds like a job for AWK! or more likely gAWK! Anything that looks like a text file is fair game!).


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 10, 2012 3:38 am 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
Thanks for the replies.
Michael, I am not using Verilog so your method will not help. Since my turnaround time is under 10 seconds, I am not simulating.
CORRECTED:
TeamTempest, the format is 16 hex bytes, high to low, so the jump instruction is followed by 0008. I watch the PC - it starts at 0 (from my reset vector) and then gets stuck at 8,9,A... E9's should be EAs - wasn't paying attention, obviously...
I downloaded Acme assembler - will try to make something more useful over the next couple of days.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 10, 2012 5:26 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
enso wrote:
fpgasm takes a file that looks like the usual BRAM init string, something like:
INIT_00::E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E900084CE9E9E9E9E9E9E9E9
INIT_01::E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9E9

In Verilog the init string looks very similar. If it is exactly the same format, you'll need to watch the bit order. The byte on the right hand side of the string is the first byte in the memory.

Here's a simple C program I've used before to do the conversion from a binary to Verilog init strings. It should be easy to modify for the slightly different syntax.
Code:
#include <stdio.h>
#include <string.h>

static char *name;
static unsigned char row[32];
static int rows;
static int n;

static void flush( void )
{
    int i;

    printf( "defparam %s.INIT_%02X=256'h", name, rows++ );
    for( i = sizeof(row) - 1; i >= 0; i-- )
        printf( "%02x", row[i] );
    printf( ";\n" );
    n = 0;
    memset( row, 0, sizeof(row) );
}

int main( int argc, char **argv )
{
    int c;
   
    if( argc < 2 )
    {
        fprintf( stderr, "%s: missing name\n", argv[0] );
        return 1;
    }
    name = argv[1];
    while( (c = getchar()) >= 0 )
    {
        row[n] = c;
        if( ++n == sizeof(row) )
            flush( );
    }
    if( n )
        flush( );
    return 0;
}

Of course, this only works for 8 bit wide memories.


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 10, 2012 2:39 pm 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
Thanks, Arlet. That's exactly what I was planning to do.

I have a question for you, actually.

Have you done any floorplanning with your core? I constrained it into a box about 1/4 of my xc3s200 so it would not spread all over the place, but it is far from optimal.

Thanks again

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 10, 2012 2:47 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
enso wrote:
Have you done any floorplanning with your core? I constrained it into a box about 1/4 of my xc3s200 so it would not spread all over the place, but it is far from optimal.

No, I just let the Xilinx tools figure out where things go. So far, I've never considered floorplanning, and wouldn't even know how to get started.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 14 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: