65Org16.x Dev. Board V1.0 using a Spartan 6 XC6LX9-3TQG144

Topics relating to PALs, CPLDs, FPGAs, and other PLDs used for the support or creation of 65-family processors, both hardware and HDL.
User avatar
BigEd
Posts: 11464
Joined: 11 Dec 2008
Location: England
Contact:

Post by BigEd »

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
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Post by ElEctric_EyE »

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.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Post by ElEctric_EyE »

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.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Post by ElEctric_EyE »

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.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Post by ElEctric_EyE »

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.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Post by ElEctric_EyE »

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: Select all

// 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: Select all

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: Select all

//////////////////////////////////////////////////////////////////////////////// 
// 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.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Post by ElEctric_EyE »

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.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Post by ElEctric_EyE »

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.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Post by ElEctric_EyE »

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.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Post by ElEctric_EyE »

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.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Post by ElEctric_EyE »

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: Select all

 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.
User avatar
Arlet
Posts: 2353
Joined: 16 Nov 2010
Location: Gouda, The Netherlands
Contact:

Post by Arlet »

If you need to logically OR several buses together in verilog, an easy solution is to declare the wires as 'wor' (Wired OR)

Code: Select all

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
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Post by ElEctric_EyE »

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: Select all

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.
User avatar
Arlet
Posts: 2353
Joined: 16 Nov 2010
Location: Gouda, The Netherlands
Contact:

Post by Arlet »

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: Select all

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: Select all

wor [15:0] do;

mem mem0( .DO(do),  ... other ports... );
mem mem1( .DO(do),  ... other ports... );
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Post by ElEctric_EyE »

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: Select all

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.
Post Reply