Author Topic: Is it OK to cherrypick a portion of whole 74 series part in CPLD Quartus II ?  (Read 2525 times)

0 Members and 1 Guest are viewing this topic.

Offline unitedatomsTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 324
  • Country: us
I am trying to learn how to use Altera Quartus II schematic entry to make simple CPLD for MAX7000A series chip. NOT using HDL, just using the schematic entry.
When I express my design using 74 logic series symbol from Maxplus2 library, I think that the symbol is a complete abstraction, representing an ideal function. So I take a larger part say 4-bit counter 74163 to implement a 3-bit counter and leave higher bit unused. The rest of unused pins go grounded or ties to logic 1 (VCC).

Question: Will Quartus figure out, that the intended function is simpler than library part, and will optimize out (remove) unnecessary nets and gates ?

Context: I am trying to develop a phase detector with 0.00x degree resolution at 10Hz..10MHz range using CPLD and FET switches. Based on old HP LCR meter from 1980s. The circuit is ECL Motorolla logic. Too difficult to attempt with my skills and today's parts. It has at leat 20 gates, flip-flops. So I think I need CMOS CPLD instead of ECL. I have modelled the digital circuit in Atmel CPLD tool and simulation worked OK. However there is no detailed timing report in Atmel tools. Only ideal 0 picosecond charts. I decided to try Intel (Altera) tools to see what CPLD can do at 80 MHz with picosecond reports, etc. And found that the best way to express logic is using symbols instead of HDL (for me personally).
Interested in all design related projects no matter how simple, or complicated, slow going or fast, failures or successes
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Anything that isn't actively used will get optimized out, it can actually be frustrating when developing a more complex project and a large part of the whole circuit gets optimized out. Usually because a clock or enable is omitted somewhere or not being driven.

The schematic entry is a waste of time though IMO, if your project only has 20 gates that should be trivial to do in VHDL or Verilog. You could pick up enough to code it at a gate level in an evening or two. I started out using the schematic entry in Quartus and later wished I had just skipped it or moved on after using it to make some trivially simple project to test my hardware. The result is proprietary non-portable code that is very hard to debug and maintain.
 
The following users thanked this post: unitedatoms

Offline unitedatomsTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 324
  • Country: us
Great. Thank you. The HDL will come much later for me. I am trying to skip learning HDL if possible. That is different level. Also the libraries could be major problem with new language. Usually new language is not that difficult, but libraries can turn to be infinite and with no feel what there in libraries or in language is mainstream vs what is poorly made and abandoned and not maintained anymore.
Interested in all design related projects no matter how simple, or complicated, slow going or fast, failures or successes
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
HDL has no concept of libraries, it is a standardized language used to describe digital logic. With HDL you are not writing a program, you are describing logic with a language that superficially resembles a program. Take a look at it, you might be pleasantly surprised. The closest thing to a library like the arduino sense will be another HDL file that can be instantiated into your project. It's not platform specific and doesn't get outdated.

D <= A AND B AND C;

That describes a 3 input AND gate in VHDL, pretty trivial. The signals can be named something more meaningful than single letters of course.

Free Range VHDL is a free e-book I found very helpful. I also gained a lot from experimenting with Grant Searle's Multicomp project.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9964
  • Country: us
For giggles, I coded up a D-flop with synchronous reset, synthesized it and copied the schematic.  The BUF type things are buffers because it is assumed that, lacking any surrounding logic, these signal originate and terminate outside the chip.

Code: [Select]
[font=courier]
entity D_flop is
    Port ( D    : in  STD_LOGIC;
           Q    : out STD_LOGIC;
           clk  : in  STD_LOGIC;
          reset : in  STD_LOGIC);
end D_flop;

architecture Behavioral of D_flop is

begin

process(clk)
begin
  if rising_edge (clk) then
    if reset = '1' then
      Q <= '0'; -- synchronous reset
    else
      Q <= D;
    end if;
  end if;
end process;

end Behavioral;
[/font]

It doesn't get much easier than this!  I attached the synthesized schematic.  Note that I got just what I expected:  A D-flop with synchronous reset.

The point of this exercise is simple:  There are only a handful of common logic blocks (I'm going to ignore edge cases like DSP, SERDES and others).  There is the basic MUX, decoder, counter, flop, register and discrete logic.  Each of these are coded to a standard, they're always the same, reset is always the first test of a clocked process (and the D-flop is an example of a clocked process) and once that standard is understood, it's like playing with LEGO.  Just pile up building blocks.  Of course, the Finite State Machine is what makes it all play  but, at its core, it is just another clocked process with a few more signals than the lowly D-flop.  But they work the same!  And just try to create an FSM with a schematic.  It might be possible but it will darn sure be complicated.  I can't even imagine what a FSM with 100+ states might look like!

It isn't a matter of code, that is pretty much standardized, it is tying the blocks together that makes a system.  You're making a bigger deal out of HDL than it is.  Every block has a coding standard (or at least 3 in the case of the MUX) and connecting them up with signals is no different than dealing in terms of wires.


« Last Edit: December 14, 2019, 07:50:21 pm by rstofer »
 
The following users thanked this post: james_s

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
I can kind of relate, I mean back before I dove in, I really couldn't grasp HDL, in my case having some conventional programming experience was a hindrance rather than a help because I had trouble letting go of the paradigm of writing instructions that are executed in sequence and into the mindset of describing hardware. Once that part is finally understood then it gets a whole lot easier. It took me a while also to get past the "HDL is really hard" mindset and realize that on a basic level it's not very hard at all.

Look at a schematic of a digital circuit and then think about how you would describe the circuit in text messages to somebody, that's essentially what HDL is doing. There are many different levels of abstraction that can be used to describe a circuit but at the lowest level it can all be described as gates, AND, OR, XOR, NOT, NAND would be NOT AND, etc.
 

Offline T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 22436
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Note that there are only so many things you can instantiate.

It is possible to construct a gate which is dual edge triggered (handy as a phase-frequency detector), and you could describe it with two IF RISING_EDGE(x) statements; this will generate an error, because the synthesizer only knows the logic primitives it was made for, and the flip-flops on the CPLD/FPGA are normal D-type (single clocked, async set/reset) so it thinks this is impossible.

Here's such a gate:



To construct such things, you have to describe it combinatorially -- that is, in terms of plain logic assignments, no events (rising/falling edges define sequential blocks).  They'll be synthesized as such -- there are only a few feedback paths (usually adder carry) within a logic block, so the synthesizer must allocate several blocks, and the resulting gate incurs several propagation delays -- it's a terribly inefficient way to do it (but, yes, it does work, you can make a multi-clocked gate as such).

The other alternative is to try and synthesize it from primitives you do have access to.  Example:



This isn't quite the same but it is with one more flip-flop added at the end.  Typically, the gates are pretty much for free and the flip-flop uses one logic block, so you end up with two instead of four propagation delays -- better performance.

All this is reflected in the pattern and type of HDL statements used.  In short, an effective way to understand HDL is, knowing what code maps to what RTL components.

Which is also an effective way to go about programming as well, for example understanding the exact semantics that C uses to select machine instructions for your program, or how an object-oriented language is built.

It is an approach which doesn't lend itself so well to portability; once you get comfortable with one architecture, you're either going to end up applying the same lessons blindly to another architecture and screw it up, or you're going to study the new architecture to the same detail and continue to succeed just as well. :P

Tim
« Last Edit: December 14, 2019, 10:14:40 pm by T3sl4co1l »
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9964
  • Country: us
I seem to recall Xilinx ISE complaining about ring-tailed NAND gates.  I haven't tried it since...
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
I don't think any of these advanced topics are going to come into play here, getting too deep into things is more likely to confuse than help him at this stage. Of course if we saw a schematic of the circuit he was trying to implement it would probably be very easy to go through translating it to HDL.
 

Offline unitedatomsTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 324
  • Country: us
I don't think any of these advanced topics are going to come into play here, getting too deep into things is more likely to confuse than help him at this stage. Of course if we saw a schematic of the circuit he was trying to implement it would probably be very easy to go through translating it to HDL.

Thank you, I will not try HDL until before begin to use FPGAs if ever. For small CPLD I am not sure if HDL does any good.
I have succeeded to reverse engineer design of old HP detector. And first time used Quartus II and ModelSim OK. I failed to see realistic skew or jitter in picoseconds in simulation. Possibly software does not model this accurate timing (tried both RTL level and Gate level simulation) for CPLD devices.

So far I have succeeded (on paper) without HDL. It is easier for me as a beginner in CPLD, to use schematics, because it is familiar language. What is amazing, is that the software after 2 days gives a lot of confidence for beginner that design is correct (outputs are expected to be correct timing wise within 3 nanoseconds plus/minus from edge of external clock). That confidence is great to have. What was most difficult is creating time constraints file . So named .sdc file.
Code: [Select]
# Clock constraints

create_clock -name "80MHz" -period 12.500ns [get_ports {CLK_80MHz}]


# Automatically constrain PLL and other generated clocks
derive_pll_clocks -create_base_clocks

# Automatically calculate clock uncertainty to jitter and other effects.
#derive_clock_uncertainty
# Not supported for family MAX7000AE

# tsu/th constraints

set_input_delay -clock "80MHz" -max 1.000ns [get_ports {Quadrature}]
set_input_delay -clock "80MHz" -min 1.000ns [get_ports {Quadrature}]

# tco and tpd constraints
set_output_delay -clock "80MHz" -max 3.000ns [get_ports {InPhaseMSBPos}]
set_output_delay -clock "80MHz" -min 3.000ns [get_ports {InPhaseMSBPos}]
set_output_delay -clock "80MHz" -max 3.000ns [get_ports {InPhaseLSBPos}]
set_output_delay -clock "80MHz" -min 3.000ns [get_ports {InPhaseLSBPos}]
set_output_delay -clock "80MHz" -max 3.000ns [get_ports {InPhaseMSBNeg}]
set_output_delay -clock "80MHz" -min 3.000ns [get_ports {InPhaseMSBNeg}]
set_output_delay -clock "80MHz" -max 3.000ns [get_ports {InPhaseLSBNeg}]
set_output_delay -clock "80MHz" -min 3.000ns [get_ports {InPhaseLSBNeg}]

The detector works in this manner. For 10 MHz signal of interest, the reference CLK frequency is 80 MHz. One control pin is "Qudrature OFF/ON". 4 output pins represent state of analog switches, 2 for positive voltage and 2 for negative. The switches (outside of CPLD) make a crude 2-bit multiplying DAC. The resulting output of DAC has DC representing "in phase" and "quadrature" component of 10 MHz analog signal being switched.
« Last Edit: December 15, 2019, 03:33:32 pm by unitedatoms »
Interested in all design related projects no matter how simple, or complicated, slow going or fast, failures or successes
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
My comment was not to dismiss HDL, it's still the way to go. The schematic capture tool is a waste of time, it's a gimmick to show off in trade show demos, nobody actually uses it. I don't know why you are so averse to trying.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9964
  • Country: us
My comment was not to dismiss HDL, it's still the way to go. The schematic capture tool is a waste of time, it's a gimmick to show off in trade show demos, nobody actually uses it. I don't know why you are so averse to trying.

Especially since half of the logic is in 8:1 multiplexers which would be coded once as a component and simply instantiated 6 times with varying inputs and outputs.  There is a 3 bit counter which would look amazingly like the D-flop I posted above (except for incrementing a count), a quad latch which would instantiated 4 times and is nothing more than a wider version of the D-flop above and, finally, a 2:1 4-channel MUX.  I guess if I were to sit down to write, the entire thing would take less than an hour.  Two, at the most.  If I counted right, there are 4 components to create plus a top module to tie them together.  Yes, the constraints file will take time.  Probably more than it took to do the logic.

But the project works, so, by definition, it's ok.  If the OP prefers schematic entry, so be it.

In this particular case, the schematic is more understandable than the HDL.  It flows nicely from left to right, there's nothing tricky about how it works.  It's a pretty clean solution.

 

Offline iMo

  • Super Contributor
  • ***
  • Posts: 5570
  • Country: va
Schematics capture is perfectly fine when you spent your life among 74xx packages.
It could be much faster than with hdl, especially when you are going to copy 1:1 an older design. The libraries (ie Xilinx ISE) include almost all you used to use decades back.
« Last Edit: December 15, 2019, 07:35:19 pm by imo »
Readers discretion is advised..
 

Offline unitedatomsTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 324
  • Country: us
Great. Thank you for moral support. I have succeeded to the point when I can choose physical pins to schematics inputs and outputs.

In regards to readability of schematics. The muxes are just a lookup tables 1-bit wide. It is easy to slap a mux and hardwire the table of what you need to happen on every state of counter. Then I rely on minimizer, which will reduce the mux to few gates. The D-Flip-Flops are my intent to express to synthesizer, that certain intermediate values must be computed same time. I think. So if it takes more than one clock, I do not care, as long as result arrive coherent across several bits. And at the output I only care about ability to capture the data with external D-Flip-Flop to erase the jitter for analog reasons.

What was not possible in WinCUPL tool, that intermediate results had to be real physical pins. (or I did not understand something about Atmel CPLDs). That caused unnecessary outputs to appear involved on chip package. In Quartus, this was not a problem. The tool says that unused pins are forced to be outputs with logic 0 value all the time. I am grounding them with 50 Ohm resistors, just in case.

It is great to have such a powerful tools for free together with full 74 series library.
« Last Edit: December 15, 2019, 11:08:09 pm by unitedatoms »
Interested in all design related projects no matter how simple, or complicated, slow going or fast, failures or successes
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
CUPL is an ancient language used for PLDs, these are much older, more primitive parts compared to CPLDs in which the C stands for Complex. It's a limitation of the old PLDs that outputs need to be physical pins, they have no interconnect network, the datasheet for the parts shows how the internal logic is wired up.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf