6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Nov 16, 2024 3:56 pm

All times are UTC




Post new topic Reply to topic  [ 241 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13, 14, 15 ... 17  Next
Author Message
 Post subject:
PostPosted: Wed Aug 31, 2011 5:33 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10980
Location: England
ElEctric_EyE wrote:
I've abandoned V1.1 of the mainboard...
I am thinking 2 Spartan 6's now. 1 containing BigEd's 65Org16.x core, the SDRAM controller core and some hardware directly controlling the CS4956 video data, and possibly a 16-bit Cypress HDD controller I've mentioned before.
The other Spartan 6 is containing Arlet's original NMOS 6502 core controlling all other I/O. That I/O being PS2 for keyboard, I2C for video CS4956 registers, SPI for serial flash, USB to 8bit parallel interface, and the TFT flat panel interface. This core would be running either the Micromon-64 or Supermon-64 as the OS. This is the nucleus of the development board I have envisioned.

Oh, are you sure about this? It sounds a bit worrying to me. You were close to getting something working, but now you're stepping into a more ambitious project. It would be great to see a single-FPGA dev board working first!

Not my project of course, and I too have a trail of unfinished ideas behind me. But one reason I managed to get somewhere with 65Org16 was by taking very small incremental steps, and breaking out of the pipedream/brainstorm mode where the ideas just pile up but there's no implementation. I still have a lot of incremental steps ahead.

The way I see it, there's no 65Org16 dev board or 6502 dev board here, there's an FPGA dev board. A lot of interesting design stuff will go on inside the FPGA, and a lot of choices, and fixes, can go on inside. The thing with the board design is to make best use of the pins of the FPGA, which is the main limited resource, and of course to get the electrical stuff correct.

Because pins are limited, I'm not sure about moving to a parallel interface for the USB chip - what's your thinking there?

Also, I'm really not sure about the dual-CPU nature of the project. Have you sketched out at a block level as to what the two CPUs are doing and how they communicate or interact? It seems to me more complexity, and I'm not sure why it's there. (Even if it is a good plan, it doesn't mean you need two FPGAs - both cores are very small. It's pin count which is most limiting, then maybe block RAM.)

If you do proceed as you sketch, you get something like a C64 with a 16-bit second processor. Why not connect the keyboard and screen direct to the 16-bit processor?

(The direction I tend to go towards is to have a host connection to a PC of some sort, so I can have a terminal connection. It would then be possible to implement a higher-level protocol over that connection, with software. For example, Tube-over-serial might be interesting.)

Not trying to be discouraging - rather, I'd like to be encouraging you to finish the smaller design first.

Cheers
Ed


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Aug 31, 2011 11:37 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
BigEd wrote:
...Because pins are limited, I'm not sure about moving to a parallel interface for the USB chip - what's your thinking there?...
Cheers
Ed

Speed, always speed is priority. Having the 65Org16 Core by itself with the SDRAM core and video controller, would allow the cpu core to run much faster without having all the other interface cores.
But I had a moment, forgive me. You are right of course. I must follow through on what I have so far, which is to make a 12MHz clock source for the USB to UART and see if I can use the config utility to control the Tx and Rx LEDs.


Last edited by ElEctric_EyE on Mon Nov 21, 2011 9:02 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Aug 31, 2011 7:57 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
It seems I took some advice from a wise man, heh. I am all ears, I always am... Thanks BigEd.
It seems I was a bit to headstrong thinking that I have had enough experience with the Spartan 3, that I could jump in and start using the extra features of the Spartan 6...
My plans were to use a Spartan 6 PLL to get 12MHz from the 100MHz main clk. Not a simple division obviously, meaning I couldn't utilize a DLL.
Turns out the in and out for the PLL must both be on the same IOB which they're not presently. This will require 1 wiring mod...

Also, I recommend the newest ISE13.2 from Xilinx. It loads much quicker. I erroneously thought my new machine was loading it 5x faster, but that was not the case, as I have installed it on my original machine as well and it initiates just as quick. Not a jab at my new machine, as I'm sure it will rip through iterations much quicker. Just a kudo's to Xilinx software division for this new version.

I ordered a USB to JTAG cable from Digilent, so I can implement the project on the new machine. The old machine uses a LPT to JTAG cable which is not sold anymore.

Also, I ordered a book from Digilent. Although the book is meant for the Spartan 3e, the Spartan 6 should have similar capabilities as far as the projects in the book are concerned.


Last edited by ElEctric_EyE on Mon Nov 21, 2011 9:03 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Sep 06, 2011 8:23 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Check here if you're interested in how I am going to get a 12MHz clock out to the MCP2200 USB-UART and a 27MHz clock out to the CS4954 from a 100MHz clock reference signal into the Spartan 6...


Last edited by ElEctric_EyE on Mon Nov 21, 2011 9:04 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Sep 07, 2011 4:49 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
It seems my question is not getting any further response to my follow up questions on their forum...
I do have another plan to use 3 DCM's and use the numbers the clock wizard used. 1 DCM to divide the 100MHz main clock by 5 then multiply by 27 to get 540MHz. Then 1 DCM to divide 540 by 20 to get 27MHz for the CS4954, and 1 final DCM to divide 540 by 45 to get 12MHz for the USB to UART.
If it works and I can measure these clocks, hopefully I'll be able to communicate with the MCP2200 USB to UART through the config program without modifying the board layout. I have not made any physical mods yet to V1.0.


Last edited by ElEctric_EyE on Mon Nov 21, 2011 9:04 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Sep 08, 2011 11:28 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Very slow day at work today...
Gave me a chance to work on the clocks. I didn't have to use DCM's after all. I used 1 of the 2 PLL's present in the Spartan 6 144-pin QFP package.

I had to work with the verilog model as the IPCore generator was giving me problems trying to implement the resultant .xco file in a schematic.
So it did pass synthesis, and it looks good in ISim generating the 12MHz and 27MHz from the 100MHz in. The necessary constraints are at the bottom. I'll report back after real world testing...

I have to keep the disclaimer attached for legal reasons.

Code:
// file: clkgen.v
//
// (c) Copyright 2008 - 2011 Xilinx, Inc. All rights reserved.
//
// This file contains confidential and proprietary information
// of Xilinx, Inc. and is protected under U.S. and
// international copyright and other intellectual property
// laws.
//
// DISCLAIMER
// This disclaimer is not a license and does not grant any
// rights to the materials distributed herewith. Except as
// otherwise provided in a valid license issued to you by
// Xilinx, and to the maximum extent permitted by applicable
// law: (1) THESE MATERIALS ARE MADE AVAILABLE "AS IS" AND
// WITH ALL FAULTS, AND XILINX HEREBY DISCLAIMS ALL WARRANTIES
// AND CONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING
// BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, NON-
// INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE; and
// (2) Xilinx shall not be liable (whether in contract or tort,
// including negligence, or under any other theory of
// liability) for any loss or damage of any kind or nature
// related to, arising under or in connection with these
// materials, including for any direct, or any indirect,
// special, incidental, or consequential loss or damage
// (including loss of data, profits, goodwill, or any type of
// loss or damage suffered as a result of any action brought
// by a third party) even if such damage or loss was
// reasonably foreseeable or Xilinx had been advised of the
// possibility of the same.
//
// CRITICAL APPLICATIONS
// Xilinx products are not designed or intended to be fail-
// safe, or for use in any application requiring fail-safe
// performance, such as life-support or safety devices or
// systems, Class III medical devices, nuclear facilities,
// applications related to the deployment of airbags, or any
// other applications that could lead to death, personal
// injury, or severe property or environmental damage
// (individually and collectively, "Critical
// Applications"). Customer assumes the sole risk and
// liability of any use of Xilinx products in Critical
// Applications, subject only to applicable laws and
// regulations governing limitations on product liability.
//
// THIS COPYRIGHT NOTICE AND DISCLAIMER MUST BE RETAINED AS
// PART OF THIS FILE AT ALL TIMES.
//
//----------------------------------------------------------------------------
// User entered comments
//----------------------------------------------------------------------------
// None
//
//----------------------------------------------------------------------------
// "Output    Output      Phase     Duty      Pk-to-Pk        Phase"
// "Clock    Freq (MHz) (degrees) Cycle (%) Jitter (ps)  Error (ps)"
//----------------------------------------------------------------------------
// CLK_OUT1____27.000______0.000______50.0______404.437____249.435
// CLK_OUT2____12.000______0.000______50.0______472.078____249.435
//
//----------------------------------------------------------------------------
// "Input Clock   Freq (MHz)    Input Jitter (UI)"
//----------------------------------------------------------------------------
// __primary_________100.000_____________0.01

`timescale 1ps/1ps

(* CORE_GENERATION_INFO = "clkgen,clk_wiz_v3_2,{component_name=clkgen,use_phase_alignment=false,use_min_o_jitter=false,use_max_i_jitter=false,use_dyn_phase_shift=false,use_inclk_switchover=false,use_dyn_reconfig=false,feedback_source=FDBK_AUTO,primtype_sel=PLL_BASE,num_out_clk=2,clkin1_period=10.000,clkin2_period=10.000,use_power_down=false,use_reset=false,use_locked=false,use_inclk_stopped=false,use_status=false,use_freeze=false,use_clk_valid=false,feedback_type=SINGLE,clock_mgr_type=AUTO,manual_override=false}" *)
module clkgen
 (  input         CLK_IN1,
    output        CLK_OUT1,
    output        CLK_OUT2   );

  IBUFG clkin1_buf
   (.O (clkin1),
    .I (CLK_IN1));
   
  wire [15:0] do_unused;
  wire        drdy_unused;
  wire        locked_unused;
  wire        clkfbout;
  wire        clkout2_unused;
  wire        clkout3_unused;
  wire        clkout4_unused;
  wire        clkout5_unused;

  PLL_BASE
  #(.BANDWIDTH              ("OPTIMIZED"),
    .CLK_FEEDBACK           ("CLKFBOUT"),
    .COMPENSATION           ("INTERNAL"),
    .DIVCLK_DIVIDE          (5),
    .CLKFBOUT_MULT          (27),
    .CLKFBOUT_PHASE         (0.000),
    .CLKOUT0_DIVIDE         (20),
    .CLKOUT0_PHASE          (0.000),
    .CLKOUT0_DUTY_CYCLE     (0.500),
    .CLKOUT1_DIVIDE         (45),
    .CLKOUT1_PHASE          (0.000),
    .CLKOUT1_DUTY_CYCLE     (0.500),
    .CLKIN_PERIOD           (10.000),
    .REF_JITTER             (0.010))
  pll_base_inst
 
    // Output clocks
   (.CLKFBOUT              (clkfbout),
    .CLKOUT0               (clkout0),
    .CLKOUT1               (clkout1),
    .CLKOUT2               (clkout2_unused),
    .CLKOUT3               (clkout3_unused),
    .CLKOUT4               (clkout4_unused),
    .CLKOUT5               (clkout5_unused),
    .LOCKED                (locked_unused),
    .RST                   (1'b0),
   
     // Input clock control
    .CLKFBIN               (clkfbout),
    .CLKIN                 (clkin1));
 
 // Output buffering
//-----------------------------------

  BUFG clkout1_buf
   (.O   (CLK_OUT1),
    .I   (clkout0));


  BUFG clkout2_buf
   (.O   (CLK_OUT2),
    .I   (clkout1));

endmodule



Constraints to make it pass synthesis, and add pin #'s, volts, etc.
Code:
NET "MAINCLK" IOSTANDARD = LVCMOS33;
NET "VIDEOCLK" IOSTANDARD = LVCMOS33;
NET "USBCLK" IOSTANDARD = LVCMOS33;

NET "MAINCLK" LOC = P123;
NET "VIDEOCLK" LOC = P92;
NET "USBCLK" LOC = P23;

PIN "XLXI_4/clkout2_buf.O" CLOCK_DEDICATED_ROUTE = FALSE; //get it to pass a strict synthesis
PIN "XLXI_4/clkout1_buf.O" CLOCK_DEDICATED_ROUTE = FALSE; //get it to pass a strict synthesis

NET "MAINCLK" TNM_NET = "MAINCLK";
TIMESPEC TS_MAINCLK = PERIOD "MAINCLK" 10 ns HIGH 50 %;



XLXI_4 is the name of the symbol created from the clkgen.v.

This is the HDL translation of the very simple top_level schematic assigning I/O pins to the design:
Code:
////////////////////////////////////////////////////////////////////////////////
// Copyright (c) 1995-2011 Xilinx, Inc.  All rights reserved.
////////////////////////////////////////////////////////////////////////////////
//   ____  ____
//  /   /\/   /
// /___/  \  /    Vendor: Xilinx
// \   \   \/     Version : 13.2
//  \   \         Application : sch2hdl
//  /   /         Filename : top_level.vf
// /___/   /\     Timestamp : 09/08/2011 19:15:07
// \   \  /  \
//  \___\/\___\
//
//Command: sch2hdl -intstyle ise -family spartan6 -verilog C:/USB/top_level.vf -w C:/USB/top_level.sch
//Design Name: top_level
//Device: spartan6
//Purpose:
//    This verilog netlist is translated from an ECS schematic.It can be
//    synthesized and simulated, but it should not be modified.
//
`timescale 1ns / 1ps

module top_level(MAINCLK,
                 USBCLK,
                 VIDEOCLK);

    input MAINCLK;
   output USBCLK;
   output VIDEOCLK;
   
   
   clkgen  XLXI_4 (.CLK_IN1(MAINCLK),
                  .CLK_OUT1(VIDEOCLK),
                  .CLK_OUT2(USBCLK));
endmodule


Last edited by ElEctric_EyE on Mon Nov 21, 2011 9:07 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Sep 13, 2011 1:26 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Got my laptop (w/Windows XP SP3) to communicate through the USB port to the MCP2200. When running Hyperterminal the Tx LED blinks each time I pressed a key. The future intent is to send a .bin file using br@y terminal @9600 baud without handshaking (4Kx8 takes about 10sec's). The data can then be directed to and stored on the non-volatile SPI Flash. Experiments will have to be done determine errors and how to get rid of them.

Will update when I get the video section working next, using the CS4954. I'll just need to generate a pattern in order to verify I can program the registers and also to make sure that the basic wiring is functional for the S-Video and Composite Out signals.

The other video section where signals are combined from the FPGA to form a monochrome composite out will not be tested yet.


Last edited by ElEctric_EyE on Mon Nov 21, 2011 9:08 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Sep 13, 2011 6:13 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Windows 7 is being abit more of a security challenge as expected. Trying to copy over the success I had on the laptop to my main system in my "lab": The MCP2200 config program works fine on Windows 7, is seeing the device and can program it. The br@y terminal program works as well, but assigning a COM port is where the problem lies. Windows 7 will not allow it so easily... I'll work on it later, not too concerned about it right now. That system is mainly for synthesizing.

On another note, as far as V1.1 of the DevBoard is concerned, I am routing the 100MHz main clock signal to a pin on each of the other 3 IOB's. So 100MHz will be available on all 4 banks. In addition, I am changing communication with the CS4954 to I2C. Also, I am adding 3 DS1085 Frequency Synthesizers (1 was used in the 6502SoC), on the backside of the board. They will also be on the I2C bus. They will be feeding their clock signals into Banks 1,2 & 3.


Last edited by ElEctric_EyE on Mon Nov 21, 2011 9:08 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Sep 15, 2011 1:37 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Win 7 not too much of a problem. I looked under device manager and saw USB drivers were not fully installed. I guess Win7 prohibited the install of the drivers during the original MCP2200 config utility setup. I was able to reinstall the drivers for the MCP2200, and the br@y terminal is sending data out, the Tx LED is blinking like in the XPSP3 laptop. I completed this task this morning...

I spent the rest of the day reworking V1.1 of the 65016 DevBoard... I was able to fit everything I had previously mentioned. I loosed the stereo audio connector, and the vga connector in order to fit a 20-pin .100" FFC adapter for a TFT display. I am going back to a TFT display for development purposes before pursuing the CS4954...


Last edited by ElEctric_EyE on Mon Nov 21, 2011 9:09 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Sep 20, 2011 12:42 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
I'm now getting closer to finalizing V1.1...

I've added 1 more IC to the I2C bus, a TSC2003 4-wire resistive touch panel controller for the 7" 800Hx480V touch panel TFT display. I've gotten rid of the 20-pin FFC to thru-hole 20-pin socket (K6) adapter from the previous pic and found a 20-pin FFC and 4-pin FFC SMD adapters on Digi-Key. This will save even more holes, which I am thankfully not struggling with right now...

To recap, I now have 3 identical DS1085L's, 1 CS4954, and 1 TSC2003 on the I2C bus. And 1 8Mb Flash device is on the SPI bus...

As far as the I2C bus, address contention arises with the 3 identical DS1085L's. Since they all come factory programmed with 1101xxx for the address bits, 1 of them will be hardwired to the SDA/SCL lines. The other 2 DS1085L's SDA/SCL lines will need to be jumpered. Then they can be programmed and 0 ohm jumpered back in 1 at a time...

Alas, I am tiring after 4 months of board design.
I want to program the 65Org16 16-bit machine for 800x480 graphics, with no 8-bit to 16-bit manipulation (as is required on the original 6502, and 65C02), on a real life machine! I would like to focus on that briefly to taste the sweetness of a 16-bit 6502, but I really have got my eye on porting a certain 6502 program to work on the 65Org16 within this system, using the aforementioned subsystem. This is truly where my ambitions are.

This board does not need to be fully populated for a minimally functional 65Org16 "system".. Absolute minimum IC's needed would be U1 (Spartan 6), and U2 (Spartan 6 PROM). U6, the 100MHz oscillator, can be disabled by J8, and the system can run if one provides an external clock.


Last edited by ElEctric_EyE on Mon Nov 21, 2011 9:10 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Sep 21, 2011 8:42 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
I double checked all my dimensions for V1.1 and tomorrow I order it!

I started working on the design for the internals today. Gonna use the same 8 bit PS2 and I2c cores I've used before, and today I found another nice 8 bit core for the SPI. All use the wishbone I/F:

Richard Herveille's I2C core.
Daniel Quintero's PS2 core.
Richard Herveille's SPI core.

So I tackled my ORs module today. Presently it is a module that takes the 16-bit data out from the zero page RAM, the stack RAM, and the ROM, logically OR's the data and sends it into the CPU data in bus. This is 48 inputs and 16 outputs. Bad enough using schematics with 3 devices. Now I need 16 6-input OR gates. 3 additional inputs on each OR gate for each of the new cores' data out.
I have decided, this will be my transition into learning verilog just out of ease of use when compared to routing so very many wires, bus taps, etc. Would have been nice if verilog recognized an OR6 like it does an OR5. This means I will have to use another module to define a 6 input OR gate, which is not so tough as I have been experimenting with simple schematic entry and viewing the HDL functional model which happens to be in verilog.

I would have liked to post here, but the code will get long. Is there any way to get scrolling windows when posting [code] here? I know someone else has suggested it recently...

EDIT: I looked it up. Leeeeee suggested it here by using a [codebox]...[/codebox]. If not, I'll start posting my modules in github.

1 thing I would like to do, prior to ordering the next V1.1board, is find a .050" jumper system, i.e. male connector & female jumper. The 3x .1" jumpers I have now are wasting alot of space and Digikey is not being very helpful.

Also, read your 0603 SMD resisitor values before soldering. They should be present on top of each piece of carbon. I only mention it now because today I soldered a 330 on a resistor that should've been marked 472 (i.e.4.7K) but was marked 330. Beware hobbyists... The auto industry thankfully demanded this resistor demarkation.


Last edited by ElEctric_EyE on Mon Nov 21, 2011 9:10 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Sep 22, 2011 12:41 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
If you need to logically OR several buses together in verilog, an easy solution is to declare the wires as 'wor' (Wired OR)

Code:
wor [15:0] bus;


And then you can just create multiple blocks driving this bus. The implementation will automatically insert an OR gate for you with enough inputs for all the drivers. Similarly, there is also an 'wand' option


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Sep 22, 2011 9:53 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Arlet wrote:
...And then you can just create multiple blocks driving this bus...

Not sure how to go about this...
This is all I've come up with so far and it's not working. Syntax error on the line with the wor. Thanks for your help. I've tried all kinds of comma's, semicolon's and other tests today to try to make it pass synthesis to try to view the RTL schematic. I must have fooled ISE at one point because it passed and I saw 1 OR gate with my INA, INB, INC [15:0] inputs and a 16-bit DO out. Afterwards, I tried to add in the IND, INE, and INF [15:0] and it failed to pass. I tried to go back and duplicate my earlier success but could not. Anyway, here is my little seedling failure at this point.
Code:
module ORs( INA,
            INB,
            INC,
            IND,
            INE,
            INF,
            DO);

    input [15:0] INA;
    input [15:0] INB;
    input [15:0] INC;
    input [15:0] IND;
    input [15:0] INE;
    input [15:0] INF;
   output [15:0] DO;
   
   
   wor [15:0] INA;
       [15:0] INB;
       [15:0] INC;
       [15:0] IND;
       [15:0] INE;
       [15:0] INF;
       //[15:0] DO;
 
  endmodule



EDIT: Upon further reflection, the "wor [15:0] bus;" is defining an output bus only I believe? I am at the earliest stages of learning verilog. I feel like I am throwing crap at a fan and seeing what sticks as far as working with the ISE verilog editor!


Last edited by ElEctric_EyE on Mon Nov 21, 2011 9:11 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Sep 23, 2011 5:30 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
Suppose you have a module 'mem' defined that implements a memory. That memory includes an output bus 'DO'.

This is how you would use it the normal way:

Code:
wire [15:0] do;

mem mem0( .DO(do),  ... other ports... );


Now, suppose you want to instantiate two of those memories, in parallel on a bus. You've designed them in such a way that produce zeros on the DO bus when not selected, so it's just a matter of OR-ing the results together.

This can be simply done this way:
Code:
wor [15:0] do;

mem mem0( .DO(do),  ... other ports... );
mem mem1( .DO(do),  ... other ports... );


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Sep 23, 2011 3:16 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
At this point I have to keep my top_level a schematic, so I couldn't follow your suggestion directly, but I think I got the jist of it from your original suggestion..

This appears to work and translates into a symbol. When viewing the RTL schematic, it appears as 1 OR with all the 16-bit wide buses connected. Now, I have to set the upper 7 bits to logical 0 on the D, E & F ports, because the lower 7 bits will be connected to the DO's of the 8-bit PS2, I2C, and SPI cores.


Code:
module ORs(   INA,
            INB,
            INC,
            IND,
            INE,
            INF,
            DO );
             
   input [15:0] INA;   
   input [15:0] INB;
   input [15:0] INC;
   input [15:0] IND;
   input [15:0] INE;
   input [15:0] INF;
  output [15:0] DO;
 
  wor [15:0] DO;
 
  endmodule


Last edited by ElEctric_EyE on Mon Nov 21, 2011 9:12 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 241 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13, 14, 15 ... 17  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 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: