Help on translate schematics to Verilog.

[BrianHG]

That design has numerous inverters all over the place where you use signals before and after the inverter.

On a circuit board, those inverters have a delay effect and some of the logic shown uses that delay to generate a 1-shot pulse for controls.

On a FPGA, those inverters are actually eliminated and have 0 delay as the compiler just uses inverted logic inputs to the appropriately driven gates.

Now, since I do not see code, I do not know how this is wired or used, but I am surprised anything worked at all.  This is unless the code you have has been heavily modified to accommodate the knowledge of the fact that those inverter buffers when compiles will have a 0ns delay instead of a 25ns delay of a 74LS04 inverter buffer.  Also, all the other buffers in the .pdf circuit will also be ignored and you should assume 0ns there.  Only the final output pins on the FPGA should be assumed to have a specific delay.  (See example image in next post...)

Now, since I do not know if you have more than 1 clock, or multiple phase clocks, and that there is a Z80 interface where an output enable control does go through a clock latch, I cant say anything about what you are doing other than I did do an authentic Z80 bus interface with a MAX10 in the past.  It was a little tricky to get right, but it did work like a charm.  Note that I had the FPGA running at 100mhz internally sourced from a different clock domain and the Z80 was running at 8mhz with it's own clock.  I did use 74LV245s powered at 3.3v to bridge the 5v bus to the max10's 3.3v IOs.  But I know with 2 separate clock domains, it can be done right.  Operating only from an external 8mhz exclusively, some logic might need to be asynchronous to meet the Z80 timings.

[BrianHG]

This part of the circuit will not be able to function as intended since the inverter will have a 0ns delay...

Because inverter 'GIA' in the FPGA has a 0ns delay, output of 'GAVIN' will always be high completely making all the logic before it ignored.  If fact, the compiler will recognize this and just prune out/remove all the logic related to this part of your schematic.  If it was someone else who coded this schematic, he must have known so and either removed the feature, or coded a work-around.

If the illustrated logic was wired using 74LSxxx ttl logic, the output of 'GAVIN' would occasionally pulse low for a few ns depending of the output of  'RIO' and 'GARETH'.

If I wanted a dumb simulation of this schematic, I would run the PLL at something like 100Mhz, and for every gate, buffer, and inverter in this schematic, I would clock them all through a DFF at 100MHz.  Though functional, it would waste a ton of FPGA logic cells where some smarter means of coding this design could be done.

[caius]

That design has numerous inverters all over the place where you use signals before and after the inverter.

On a circuit board, those inverters have a delay effect and some of the logic shown uses that delay to generate a 1-shot pulse for controls.

On a FPGA, those inverters are actually eliminated and have 0 delay as the compiler just uses inverted logic inputs to the appropriately driven gates.

Now, since I do not see code, I do not know how this is wired or used, but I am surprised anything worked at all.  This is unless the code you have has been heavily modified to accommodate the knowledge of the fact that those inverter buffers when compiles will have a 0ns delay instead of a 25ns delay of a 74LS04 inverter buffer.  Also, all the other buffers in the .pdf circuit will also be ignored and you should assume 0ns there.  Only the final output pins on the FPGA should be assumed to have a specific delay.  (See example image in next post...)

Now, since I do not know if you have more than 1 clock, or multiple phase clocks, and that there is a Z80 interface where an output enable control does go through a clock latch, I cant say anything about what you are doing other than I did do an authentic Z80 bus interface with a MAX10 in the past.  It was a little tricky to get right, but it did work like a charm.  Note that I had the FPGA running at 100mhz internally sourced from a different clock domain and the Z80 was running at 8mhz with it's own clock.  I did use 74LV245s powered at 3.3v to bridge the 5v bus to the max10's 3.3v IOs.  But I know with 2 separate clock domains, it can be done right.  Operating only from an external 8mhz exclusively, some logic might need to be asynchronous to meet the Z80 timings.

The schematics are the 1:1 representation of silicon die of the custom chip and code is made from them (after the author figured out how the chip works)
Sorry, I forgot to attach code, here you go.
There is only one clock  (labeled HCLK in schematics)

[BrianHG]

The schematics are the 1:1 representation of silicon die of the custom chip and code is made from them (after the author figured out how the chip works)
Sorry, I forgot to attach code, here you go.
There is only one clock  (labeled HCLK in schematics)

Is this your code?
There may be 1 HCLK input, but, there are multiple clocks generated from resulting registers and other logic.

As for weird resulting clocks, IE:

Code: [Select]

assign MELVIN = ~|{HCLK, ~HINT};

always @(posedge MELVIN)
MARK_Q <= BLTM;

The author is using a clock for MARK_Q & KEITH_Q instead of using clock enables.  However when copying a TTL schematic, this is how you would expect to write it.  All this means is in a FPGA, the results MARK_Q & KEITH_Q are slowed down by the newly generated clock net.  This can create timing bugs, however since your error is corrected external to the FPGA, I do not believe that this is where your problems lie.

Is this code the top of your hierarchy?  Or, do you have a separate module tying this code's IO ports to the FPGA IOs?

For example, you said you once tried to use a PLL, where would you have placed that PLL?

[caius]

Is this your code?

I'm not the author of the code, it has been written by the guy who decapped and traced the silicon die.
 

There may be 1 HCLK input, but, there are multiple clocks generated from resulting registers and other logic.

As for weird resulting clocks, IE:

Code: [Select]

assign MELVIN = ~|{HCLK, ~HINT};

always @(posedge MELVIN)
MARK_Q <= BLTM;

The author is using a clock for MARK_Q & KEITH_Q instead of using clock enables.  However when copying a TTL schematic, this is how you would expect to write it.  All this means is in a FPGA, the results MARK_Q & KEITH_Q are slowed down by the newly generated clock net.  This can create timing bugs, however since your error is corrected external to the FPGA, I do not believe that this is where your problems lie.

I can see, thanks for explanation.

Is this code the top of your hierarchy?  Or, do you have a separate module tying this code's IO ports to the FPGA IOs?

This is the top module, I have simply assigned code IO ports to FPGA IOs in Quartus pin planner.

For example, you said you once tried to use a PLL, where would you have placed that PLL?

Well, I simply used the Quartus wizard for PLL following (and adapting) the attached tutorial.As PLL input I used the same 8MHz HLCK or clock signals from external oscillators (tried different values, 32MHz, 24MHz, etc..).Perhaps this is not the right way (I'm a dumb, I know...)

[BrianHG]

For the PLL, what you want is a simple PLL, 8MHz in, 8MHz out.
It is the output phase you want to adjust.
Something like +/-45 degrees, or 90 degrees.

Remember, you want the PLL source clock to be a dedicated clock input pin.

Then, the output of the PLL should feed the verilog source code's input.

Originally I assumed you had your own verilog source module which was wired to the IO pins, which was wired to the source module you provided above.  This was where I thought you were inserting your custom PLL or LCELL logic.  Without having your own middle man module, I see how you may have difficulty adding your own middleman logic buffers, delays, inverters, or anything other logic you might be trying to add as a max10 is a little overkill for the provided logic.

[xvr]

A lot of generated clocks, as BrainHG say. In this form it will not work. You need to recreate all RTL based on logic of original schema, but made if fully synchronous. You can use PLL to boost original 8MHz clock to some high frequency clock to have a room for maneuvers, it definitely will help (ratio of speed of original circuit and speed of MAX FPGA will allow using of a LOT of ticks to implement logic that originally would be fit in one tick).
But it is not an easy task.

Alternatively you can try implement original schema, using low level primitives of FPGA and disabling optimization in synthesizer, but it quite hard and do not grantee result  Timing of FPGA primitives is different from timing of original logic.

[caius]

For the PLL, what you want is a simple PLL, 8MHz in, 8MHz out.
It is the output phase you want to adjust.
Something like +/-45 degrees, or 90 degrees.

Remember, you want the PLL source clock to be a dedicated clock input pin.

Then, the output of the PLL should feed the verilog source code's input.

Originally I assumed you had your own verilog source module which was wired to the IO pins, which was wired to the source module you provided above.  This was where I thought you were inserting your custom PLL or LCELL logic.  Without having your own middle man module, I see how you may have difficulty adding your own middleman logic buffers, delays, inverters, or anything other logic you might be trying to add as a max10 is a little overkill for the provided logic.

I can try to implement a PLL if you assist me

[caius]

A lot of generated clocks, as BrainHG say. In this form it will not work. You need to recreate all RTL based on logic of original schema, but made if fully synchronous. You can use PLL to boost original 8MHz clock to some high frequency clock to have a room for maneuvers, it definitely will help (ratio of speed of original circuit and speed of MAX FPGA will allow using of a LOT of ticks to implement logic that originally would be fit in one tick).
But it is not an easy task.

Alternatively you can try implement original schema, using low level primitives of FPGA and disabling optimization in synthesizer, but it quite hard and do not grantee result  Timing of FPGA primitives is different from timing of original logic.

I can try to implement the original schematics using Quartus primitives, the only doubt is how to model the RAM blocks (perhaps using the Quartus MegaWizard).How to disable optmization on Quartus snthesizer?

[BrianHG]

I made you a PLL 8mhz to 8mhz project.

If you want to edit the PLL settings, just open the project, open the source file and edit.

For you FPGA project, just include the 'clk_8mhz_to_8mhz.v' in that project 'add/remove source files' and add it to your source code.

To help you out, I still say make your own top hierarchy module which calls your Verilog.v 's 'custom' module so you may wire things inbetween...

[caius]

I made you a PLL 8mhz to 8mhz project.

If you want to edit the PLL settings, just open the project, open the source file and edit.

For you FPGA project, just include the 'clk_8mhz_to_8mhz.v' in that project 'add/remove source files' and add it to your source code.

To help you out, I still say make your own top hierarchy module which calls your Verilog.v 's 'custom' module so you may wire things inbetween...

Many thanks, appreciate it.I'll try to implement it in my project althought I did not undertand if I have to add the Verilog file to my project or the Verilog code of the PLL to my Verilog code.Sorry but I'm try to learn from you masters of electronics

[BrianHG]

Maybe you should start a new project and make your own caius_top.v and we can take it one step at a time.

In your 'caius_top.v' module, since you will be placing the poorly named 'custom' module inside with the same port names, you should copy the port names at the top, where all you would change is the output reg to output, like so...

file 'caius_top.v':

Code: [Select]


`include "Verilog.v"  // again stupid file name, but this is what you called it when you sent us 'verilog.txt'.
// Anyways, the include will tell Quartus to automatically add 'Verilog.v' which should be located in the same directory to your new project.

module caius_top(  // this is your top module.  Quartus should be told that this is your top module and your IO pins should be wired to the net names below.
     input              nRST,
               
     input        [7:0] D,
     output wire  [8:0] A,
               
     output wire        nDMA,
     input              nRDY,
     output wire        nBRQ,
     input              nBAK,
               
     input              BLTM,
     input              FLIP,
               
     input       [8:1]  V,
               
     input              EINV,
     input              nHLD,
     input              HCLK,
     output wire  [9:1] H,
               
     output wire        HINT,
     output wire        nTR3,
               
     input              VFLP,
     output wire  [3:0] VLB,
               
     input              MATCH1,
     output wire        OUT54,
     output wire        OUT55,
     output wire        OUT57,
               
     output wire  [7:0] POS,
     output wire  [7:0] CHR,
     output wire  [7:0] ATR
);

// Instantiate module 'custom' from the source file 'Verilog.v' here...
custom custom_inst_1 ( // Again, this custom name of custom for your third party's logic is just silly...
.nRST     ( nRST   ),

.D        ( D      ),
.A        ( A      ),

.nDMA     ( nDMA   ),
.nRDY     ( nRDY   ),
.nBRQ     ( nBRQ   ),
.nBAK     ( nBAK   ),

.BLTM     ( BLTM   ),
.FLIP     ( FLIP   ),

.V        ( V      ),

.EINV     ( EINV   ),
.nHLD     ( nHLD   ),
.HCLK     ( HCLK   ),
.H        ( H      ),

.HINT     ( HINT   ),
.nTR3     ( nTR3   ),

.VFLP     ( VFLP   ),
.VLB      ( VLB    ),

.MATCH1   ( MATCH1 ),
.OUT54    ( OUT54  ),
.OUT55    ( OUT55  ),
.OUT57    ( OUT57  ),

.POS      ( POS    ),
.CHR      ( CHR    ),
.ATR      ( ATR    )

);


endmodule


Again, all I did here was make you a top module in your name directly wired to the 'custom' module from the file 'Verilog.v'.
Step 1 is just to get this to work just like it does now when the 'custom' used to be the top in your project.
Then, step #2 will be to cut a wire between the IO pins in your 'top', send that signal name through some custom logic like a PLL, then pass the output of that PLL to the instantiated 'custom' module below.

[Wiljan]

You could output the clk on the FPGA on a pin so you can see on a scope what actually happens to the clk phase / stability in respect to the input with / without the TTL buffer

[caius]

You could output the clk on the FPGA on a pin so you can see on a scope what actually happens to the clk phase / stability in respect to the input with / without the TTL buffer

That's a good idea, thanks.Anyway, I forgot to mention that all inputs from the hosting haardware to the FPGA (including the clock) are translated from 5V to 3.3V using bus transcerivers like these :

https://www.mouser.it/ProductDetail/595-SN74LVC245ARGYR

https://www.mouser.it/ProductDetail/771-74ALVC164245

Perhaps this design may alter the clock signal?

[caius]

I implemented the PLL and improved things.Now the sprites are almost perfect, there are only some little glitches (like sparkling pixels).Which are the parameters in PLL I can play with?Thaks again for the help.

[BrianHG]

Open the 'max10pll_8m_to_8m' project I sent you.
Open the PLL source file 'clk_8mhz_to_8mhz.v'.
You should get the PLL megawizard.

On page 6 of 12, -> C0 core output clock,

You will see I set the phase to 45 deg.

Try 90 deg, or 22.5 deg or 67.5 deg.

If these don't help, by no means try 180 deg, otherwise, all along, all you needed was to invert your clock.
You should also try 180-22.5 (157,5) deg, and 180+22.5 (202.5) deg.

Again, we aren't truly solving your issue of why the circuit isn't functioning the way you want, we are just placing a skew on the internal clock and hoping for the best.

To play it safe, once you got it working, I would add a crap load of heat to your FPGA board to make sure the clock offset you chose will still function error free under extreme circumstances.  I used to use a hair-dryer to heat up my circuits when I would attempt dirty solutions like this.

One last thing you could try is at the bottom of page 3 of the PLL megawizard:
'How would you like to set the PLL bandwidth settings...'
Switch from Auto to 'Low' or 'High'.
Low means a noisy source clock will be smoothed out.  But, if your device deliberately operates within the noise, then you will need to set the bandwidth to High so that the PLL follows the jittery-ness of the source clock.

[caius]

Thanks.I tried different parameters.I got big improvements with these settings (sprites almost perfect, just very little and inappreciable glitches)

               

Code: [Select]

altpll_component.bandwidth_type = "LOW",
altpll_component.clk0_divide_by = 1,
altpll_component.clk0_duty_cycle = 50,
altpll_component.clk0_multiply_by = 1,
altpll_component.clk0_phase_shift = "23438",
altpll_component.compensate_clock = "CLK0",
altpll_component.inclk0_input_frequency = 125000,
altpll_component.intended_device_family = "MAX 10",
altpll_component.lpm_hint = "CBX_MODULE_PREFIX=clk_8mhz_to_8mhz",
altpll_component.lpm_type = "altpll",
altpll_component.operation_mode = "NORMAL",
altpll_component.pll_type = "AUTO",
I get no glitches at all with the following settings, I know the period of the clock input is wrong (100000 means 10MHz whereas I have 8MHz) but it's really perfect now.I let run the board for a couple of hours and it's stable also heating it with an hair dryer.

               

Code: [Select]

altpll_component.bandwidth_type = "LOW",
altpll_component.clk0_divide_by = 1,
altpll_component.clk0_duty_cycle = 50,
altpll_component.clk0_multiply_by = 1,
altpll_component.clk0_phase_shift = "15625",
altpll_component.compensate_clock = "CLK0",
altpll_component.inclk0_input_frequency = 100000,
altpll_component.intended_device_family = "MAX 10",
altpll_component.lpm_hint = "CBX_MODULE_PREFIX=clk_8mhz_to_8mhz",
altpll_component.lpm_type = "altpll",
altpll_component.operation_mode = "NORMAL",
altpll_component.pll_type = "AUTO",

[BrianHG]

So a 15.625ns delay worked well, a delay time similar a LVC buffer gate. what else?

If you wanted to code synchronous logic, you could always open another clock C1 output running at 2x,4x,8x,16x of C0 and write synchronous code of your own which thinks in synchronous steps allowing up to 16 equally spaced sub steps between input and output.  However, this would require learning some verilog.

Things like small ram, dual port ram, are roms are easy to code and having a core clock running at 4x your bus clock means reade operations can be done and ready within a single 8Mhz clock whereas a Z80 usually gives you 3 cycles to have the data ready.  Having a core 8x or 16x clock means a read address given at the rise of an external 8MHz clock can have valid read data returned before the fall of that same input clock.

If you were to use the 'LCELL' buffer to delay the clock, you would need something like 8 of them in series to pull off the same delay as you have set in your PLL.  The PLL will be more precise and more temperature immune.  The LCELL can achieve tiny delays if necessary and you can sprinkle multiple ones across your design and they work on any signal, not just clocks where as you only get 1 PLL ant it only works for clock signals, but you can have multiple clock outputs at multiple phases and at multiple frequencies which divide into an even integer of your source clock.

[caius]

So a 15.625ns delay worked well, a delay time similar a LVC buffer gate. what else?

Yes, it worked well but I used this setting :

Code: [Select]

altpll_component.inclk0_input_frequency = 100000,
instead of the correct one for a 8MHz signal :

Code: [Select]

altpll_component.inclk0_input_frequency = 1025000,
Does it matter?

[BrianHG]

You can get away with an error in the reference clock setting, however, make sure your output is set to 10mhz instear of 8mhz.

Having 8mhz might also give your phase offset finer resolution.

I know it is set to 15625ps.  This doesn't mean if you set it to 15620ps that the output will be any different.  At low frequencies, the PLL may have 11.25 degree or 5 degree phase resolution steps while at 200mhz, the phase step resolution may only be in 45 degree increments.

I would say change it to the proper 8mhz as Quartus needs to configure the Max10's internal PLL  oscillator which is actually running between 500mhz and 850mhz, then dividing that output back down to you selected clock frequency.  Placing a false 10 where you did may mean the Max10 PLL oscilator may be forced to run out of spec, down at 450mhz.  It will work, but it supposed to run higher and some Max10s might not reach down to 450Mhz without loosing PLL lock.

[BrianHG]

instead of the correct one for a 8MHz signal :

Code: [Select]

altpll_component.inclk0_input_frequency = 1025000,
Does it matter?

1000000/8mhz = 125000.

[caius]

instead of the correct one for a 8MHz signal :

Code: [Select]

altpll_component.inclk0_input_frequency = 1025000,
Does it matter?

1000000/8mhz = 125000.

Yes, sorry, I made a typo.I was meaning 125000

So these settings are wrong (because I set a period of 100000=10MHz) but they work perfectly :

               

Code: [Select]

altpll_component.bandwidth_type = "LOW",
altpll_component.clk0_divide_by = 1,
altpll_component.clk0_duty_cycle = 50,
altpll_component.clk0_multiply_by = 1,
altpll_component.clk0_phase_shift = "15625",
altpll_component.compensate_clock = "CLK0",
altpll_component.inclk0_input_frequency = 100000,
altpll_component.intended_device_family = "MAX 10",
altpll_component.lpm_hint = "CBX_MODULE_PREFIX=clk_8mhz_to_8mhz",
altpll_component.lpm_type = "altpll",
altpll_component.operation_mode = "NORMAL",
altpll_component.pll_type = "AUTO",

How can I achieve the same resuts with a setting of 125000=8MHz that reflects what I have (real clock is, indeed,  8MHz)?

[BrianHG]

Try shrinking the clk_0 phase by 2-5 ns.  The internal clock will be 8mhz either way.  Going to 10mhz might only affect the automatic 'PLL Bandwidth', changing it from 'low' to 'medium' as 5mhz and 10mhz may be a transition point for the pll's phase comparator and lying to quartus just makes quartus jump up that setting by 1 making the PLL more responsive to a noisy clock source.  You haven't actually changed the PLL's output clock frequency.  EG: make a spare IO pin equal to the PLL clock and check the 2 signals together on your scope, clkin and clkout, you will see they are the same.  (IE, if your source clock has some noise, then the PLL output needs to track that noise for your circuit to run good.)

In your design, you do not have any properly clocked ram.  All you have are 3 static rams.  The way they are written makes some things flaky as you have some posedge and negedge clocks as well surrounding their address controls, however, when copying someone else's hardwired logic or IC process, this may be the quickest route to success.

Using a clk_1 output running at 90 deg out of phase from clk_0 to latch/clock the ram data or address controls can help.  Or making clk_1 run at 4x where you clock the ram's address and controls running at this speed would also help.

Again, this design uses so many different clocks at so many little points that it would be hell to fiddle with it.  If you are re-writing your own code, then you might want to take things your own way.

The design appears to clock it's ram from 'different' multiple input source conditions, including the main clock.  Delaying the main clock with the phase probably allows all the states of the multiple inputs to settle before any action takes place.  With multiple negedge and posedge triggers in the code, you would need to decide which things gets moved where.

When setting up the PLL did you try -45 deg, or 180+/-45deg to see if you get a larger sweet spot of operation?


Memory is simple in verilog.  However, the way data is being written with multiple write clock sources for 1 ram instead of what we are used to seeing, 1 clock source for the ram's write port, then multiple selectable states for the 'write-enable'.  Same for the read port.  It could be the same system ram clock, or, it's own clock, preferably with a latched read address, then latched data output for best FMAX performance.  Again, this design uses the ram in static read mode, though, at 8mhz, the max10 can do this with ease as having the read address and data latched would allow the max10 to run the ram at a whopping 250mhz.  But when you send a read address, that address data output is pipe delayed by 2 clocks.

[caius]

When setting up the PLL did you try -45 deg, or 180+/-45deg to see if you get a larger sweet spot of operation?

No, I did try only 90 deg,  45 deg, 22.5 deg and 67.5 deg.
About RAMs, the author of the code told me he chose to do RAMs with registers and not block because the latter do require high speed clock

[BrianHG]

When setting up the PLL did you try -45 deg, or 180+/-45deg to see if you get a larger sweet spot of operation?

No, I did try only 90 deg,  45 deg, 22.5 deg and 67.5 deg.
About RAMs, the author of the code told me he chose to do RAMs with registers and not block because the latter do require high speed clock

False.  Ram blocks can be configured as static memory as well.

And, quartus most likely auto-converted your registers to ram blocks behind your back.  You would have to inspect the compiler report to check.  It is only a question if Quartus auto-interpreted your code accordingly.

Another thing you can try is setting the compiler optimization to operate for speed instead of balanced.  It will eat a few extra gates, but the IO timing will be a little tighter.