Spartan® Family FPGAs

[mow2000]

My initial post really focused on connecting two spartan boards.  I wanted to get that out of the way initially then debug the code.  The code I posted was just simple test code which I hadn't intended to publish or deliver. 

It appears that the issue is simply this "setup" necessity which I was unaware of.  No amount of commenting or code analysis could have uncovered this on my part.

I'm new to verilog, etc but have years of experience doing high quality software engineering in a variety of industries.

[eteam00]

I hadn't considered setup time.  My thought was that the clock and data would transition together (for example clock high and data[0] high).  The receiver would see a posedge and a data[0] high and read that as a '1' bit.  I didn't realize I needed a setup time.

Setting data1out <= 0 was actually a hack to try to fix the problem.

I'm sure that your understanding of the differences between hardware and software design will grow over the years.  Until then, you are a hardware novice, and design reviews by others are not just a nice idea.  They are an opportunity to correct mistakes and provide (to you) needed understanding of how hardware works.  Comments in your code, combined with overall descriptions of 'how my design is intended to work', will undoubtedly improve the efficiency and yield of design reviews.

If you cannot justify comments and explanations for your own needs, then do it for your colleagues who are likely to review your designs or maintain your designs after you have moved on to bigger and better things.

It appears that the issue is simply this "setup" necessity which I was unaware of.  No amount of commenting or code analysis could have uncovered this on my part.

Perhaps comments in your code would not have helped you (although I disagree on this point), but they certainly could not hurt.  Avoiding comments certainly did not help.  I'd like to think that a comment such as "this line is a hack to correct false 1s at the receiver" would immediately attract Gabor's attention -- and perhaps even my attention.

Seriously, I am quite amazed that I am trying to convince an experienced software engineer that comments are good!  Has the world turned upside down?

Maybe I'm disproportionately exaggerating this issue.  This is a 'teaching' forum, so I try to exploit every possible teaching opportunity as it arises.

I'm new to verilog, etc but have years of experience doing high quality software engineering in a variety of industries.

The design debugging skills you have developed over years of software development work should apply equally to the task of hardware debugging.  The details differ, but the principles and approach are the same.

-- Bob Elkind

[rcingham]

"I ... have years of experience doing high quality software engineering"

I am guessing that this didn't involve much 'bit-banging' of interfaces, otherwise you would already know about clock/data relationships. For slow interfaces, like I2C and SPI, generally the Master issues data on one clock edge, and the Slave samples it on the other. With FPGA versions of Slave interfaces with much faster clocks available internally, this fast clock drives logic which detects the edge, then samples the data.

Although Verilog looks a bit like certain software languages it is still HARDWARE design (similarly for VHDL).

[mow2000]

In regard to "setup time".  Suppose I did something like:

reg a; // a

always @(posedge CLK)  // on positive edge of my 00.1 Hz clock

   a <= CLK;  // set a to CLK level

Given that a doesn't have any "setup time" would it occasionally be set to zero?

[rcingham]

My Verilog-fu is not good, but it appears that what you are suggesting is nonsensical from a hardware point of view.

If we go back to a rudimentary interface, what you want is something like:

loop // free-running clock assumed here...
  Master sets CLK to 1
  Master drives DATA
  Master waits half clock period
  Master sets CLK to 0
  Slave samples DATA
  Master waits half clock period
repeat; //rinsing is optional

 
I suspect that use of the push-button is a confounding factor that is leading you up a blind alley.

This is a orthogonal problem to the inter-board voltage issue. For fast serial interfaces, these are often AC-coupled, BTW, so that the baseline voltages can be different without inducing ground loops.

[mow2000]

Well Bob...  You haven't yet answered a single question.  You completely skipped over the question implied in my first posting so maybe I need to give you a lecture on reading and understanding what you're reading.  If we had simply started there you could have saved quite a bit of time which you devoted to Computer Science 101 lectures.  But you didn't because it didn't serve your purpose.

Your intent is not a "teaching opportunity" but a control opportunity to make up for deep-seated inadequacies in your own life.  Every forum has a pitiful, little, anally retentive bully like you who wiles away his weekend ready to pounce on the next hapless passerby.  You're that guy.

[mow2000]

My question was academic and related to setup time.  Would the register a ever be zero when CLK is 1.  If so then the setup idea doesn't hold water.

I'm just trying to nail down these concepts.

In my first posting I said "I've thought about using opto-couplers..."

[eteam00]

In regard to "setup time".  Suppose I did something like:

reg a; // a

always @(posedge CLK)  // on positive edge of my 00.1 Hz clock

   a <= CLK;  // set a to CLK level

Uhhhhhh... no.

Hardware lesson #1, do not use a clock as both data and clock for the same register.  The resulting behaviour is most likely indeterminate and inconsistent.  If the behaviour is consistent, output will be constant '0' or constant '1', either of which can be generated without a clock or a register.

You need a hardware mentor.  Are there any hardware nerds where you work?

Rcingham had it right when he described how low-frequency interfaces are typically handled:

generally the Master issues data on one clock edge, and the Slave samples it on the other.

Or you can try my pseudo code:

Start:  set output clock LOW

        wait for <button press>

        update output data

        insert delay here for additional SETUP time

        set output clock HIGH

        insert delay here for additional HOLD time

        loop to Start

Either approach may require a state machine or delay counter, depending on the frequency of the system clock "CLK".

How is the debouncedbuttonpress signal generated?  If it is a single cycle pulse, you can use this signal (properly delayed) as the output clock.

Pseudo code #2:

Start:  wait for <debouncedbuttonpress >

        update output data

        output delayed copy of debouncedbuttonpress as the output clock

        loop to Start

Three solutions for you.  Do any of these make sense?

-- Bob Elkind

[mow2000]

That's a good guess.  I humbly apologize for not having much experience banging bits.  I really do and I'm beginning to have serious regrets about posting anything on this forum!  But such is life :)

[eteam00]

Your intent is not a "teaching opportunity" but a control opportunity to make up for deep-seated inadequacies in your own life.  Every forum has a pitiful, little, anally retentive bully like you who wiles away his weekend ready to pounce on the next hapless passerby.  You're that guy.

OUch!  If you met me in person, you would probably think even less of me...  And I'm not little!

-- Bob Elkind