Looking for someone able to translate Kicad schematics into HDL (Verilog/VHDL)

[caius]

Hi all,
I'm looking for someone able to translate some of my Kicad projects into valid HDL (Verilog is preferend but also VHDL is accepted).Schematics are mostly made with simple TTL logics (74 family), sometimes RAMs and PLDs.Remuneration at the end of a successful job or on each sale (Verilog/VHDL code will be used on commercial devices I will put for sale).Highest seriousness.Possibility of long-term collaboration.Contact me here in private or to my email fo more details.Thanks

[DC1MC]

It will help if you could post a sample project, while every digital design can be expressed in HDL, not every HDL project is synthesizeable and I assume you actually want to put the design in a FPGA or just run simulations ?

Also it will be nice to specify your chosen platform, is it Lattice, Xilinx, Intel/Altera or didn't decide yet.

 Cheers,
 DC1MC

[caius]

Thanks for reply
I want to put the designs in old +5V CPLDs like Altera MAX7000 (or compatible Atmel ATF15XX) using Quartus.I already done such projects but I took care of the hardware part only (designing a proper board), code was written by someone else.I attach a snippet of schematics as example.

[RoGeorge]

Quartus still have a schematic editor that can be used instead of HDL.  Vivado doesn't.

[caius]

Quartus still have a schematic editor that can be used instead of HDL.  Vivado doesn't.

I know and indeed I use the old Quartus 12.1 which still has support for MX7000 CPLD.The problem is that my schematics have been done in Kicad and porting them to Quartus block diagram is a huge job.

[tggzzz]

Your strategy is wrong.

You should define the behaviour  of your design, as currently implemented in 74 series logic. That will allow the behaviour to be reimplemented in a different technology.

If you don't do that then you may well be reimplementing irrelevant details of the current implementation.

BTW, I first saw this problem in 1982, where the reimplementation technology was PALs. The fundamentals haven't changed in 40 years!

[caius]

Your strategy is wrong.

You should define the behaviour  of your design, as currently implemented in 74 series logic. That will allow the behaviour to be reimplemented in a different technology.

If you don't do that then you may well be reimplementing irrelevant details of the current implementation.

BTW, I first saw this problem in 1982, where the reimplementation technology was PALs. The fundamentals haven't changed in 40 years!

Yes, I know this will be the right way but I don't have the skills so I was thinking to simply translate schematics but, evidently, I was wrong 
OK, none want to help me  We could have had fun together!

P.S.
Just to punctualize.The devices where the HDL designs must be implemented are replacemet parts for arcade PCBs.Just some example from my blog of TTL and CPLD (with code written not by me) implementation :

https://caiusarcade.blogspot.com/2020/03/namco-02xx-reproduction.html

https://caiusarcade.blogspot.com/2020/03/namco-04xx-reproduction.html

https://caiusarcade.blogspot.com/2020/03/taito-pc060ha-reproduction.html

[AndyC_772]

You should define the behaviour  of your design, as currently implemented in 74 series logic. That will allow the behaviour to be reimplemented in a different technology.

Ordinarily I'd agree with you; writing the HDL in a way which describes the desired behaviour of the whole circuit is clearer, less prone to bugs, and easier to maintain.

However, in this case I'm not sure it's the best approach...

- this design is 'dead', as in, it's obsolete tech which is no longer being maintained or developed in any way. There's no expectation that the function of the logic will ever be changed - though it might be ported to a new programmable device in future. This means it's a good decision to recreate the logic in HDL that can be recompiled for any device, rather than rely on the schematic entry tool of one particular FPGA vendor, but the HDL itself is unlikely to have to change.

- the 74 series logic in the schematic is definitively correct. The customer has already done the reverse engineering, created the circuit, built it, tested it, and confirmed that it works.

- therefore, the goal of implementing a redesign in a programmable device is to replicate that known-good circuit in a way which minimises risk, and maximises the ability of all parties involved to see that the HDL does indeed represent the known-good logic.

Bear in mind also that the the synthesis tool will reduce the HDL to a truth table. It really doesn't matter to the synthesizer how elegant - or not - the source code is. Its function is to determine what pattern of outputs should correspond to each pattern of inputs, and then to figure out how best to make the logic blocks in the CPLD deliver the desired result. The CPLD is built out of look-up tables and D-type latches, so that's what the HDL must be reduced to.

With all that in mind, if I were doing this job, I'd probably start by creating a separate (VHDL) process for each IC, each of which would only need to contain a few lines of code which describe the function of that particular device. For really simple circuits I might combine a few devices into a single process to avoid making the code excessively verbose. (Unless it's an academic example, nobody needs a whole process just for a logic gate).

I think the most difficult part would be the logistics of testing. If it doesn't "just work", is the HDL correct? The pin-out? Voltage thresholds? Static timing? An output glitch? Signal integrity? I can think of plenty of reasons why a relatively modern, high speed logic device might not just drop straight into a board designed 30 years ago - and none of them would be due to the logic itself being "wrong".

[caius]

I think the most difficult part would be the logistics of testing. If it doesn't "just work", is the HDL correct? The pin-out? Voltage thresholds? Static timing? An output glitch? Signal integrity? I can think of plenty of reasons why a relatively modern, high speed logic device might not just drop straight into a board designed 30 years ago - and none of them would be due to the logic itself being "wrong".

That's often happen when you replace an old part wit modern high speed logic device but this can be figured out in a later moment by doing testing/debugging on target platform.The hardest part is embedding all the 74 logics (especially asynchronous circuit) in a piece of HDL code I think.Anyway, my offer is still valid 

[tggzzz]

I think the most difficult part would be the logistics of testing. If it doesn't "just work", is the HDL correct? The pin-out? Voltage thresholds? Static timing? An output glitch? Signal integrity? I can think of plenty of reasons why a relatively modern, high speed logic device might not just drop straight into a board designed 30 years ago - and none of them would be due to the logic itself being "wrong".

That's often happen when you replace an old part wit modern high speed logic device but this can be figured out in a later moment by doing testing/debugging on target platform.The hardest part is embedding all the 74 logics (especially asynchronous circuit) in a piece of HDL code I think.Anyway, my offer is still valid 

The 74 series specs are published and could be duplicated.

What is the spec of the CPLD devices? That needs to include the specific fusemap. Good luck with that.

[caius]

The 74 series specs are published and could be duplicated.

Yes, someone has also translated to Verilog :

https://github.com/TimRudy/ice-chips-verilog

What is the spec of the CPLD devices? That needs to include the specific fusemap. Good luck with that.

Datasheet attached.

[tggzzz]

The 74 series specs are published and could be duplicated.

Yes, someone has also translated to Verilog :

https://github.com/TimRudy/ice-chips-verilog

What is the spec of the CPLD devices? That needs to include the specific fusemap. Good luck with that.

Datasheet attached.

Useless; that's the blank unprogrammed device. You need the fusemap for the specific application. And even if you had that it would be a herculean task to reverse engineer what it is doing and how it is doing it

[caius]

Useless; that's the blank unprogrammed device. You need the fusemap for the specific application. And even if you had that it would be a herculean task to reverse engineer what it is doing and how it is doing it

Obviously I need the .POF file, I'm not stupid.The problem is embedding all the 74 logics into valid Verilog and then generate the .POF 
Anyway, perhaps you didn't get well the whole matter.I'm not making reverse-engineering because I already have the functionality reverse-engineered into simple TTL gates  Now it's just matter to condense this logics into a CPLD.

[caius]

To make people understand here's an example.Attached are pictures of original chip and its reverse-engineering into TTL gates.A CPLD will be the best solution to obtain a board with more or less same dimensions of original chip, not to mention that it would be cheaper and easy/quick to assemble.The TTL version is huge and ugly although it works perfectly on target system.

[james_s]

Is that an arcade board?

This should be fairly trivial, if I didn't have so many projects on my plate already I'd take a crack at it.

[caius]

Is that an arcade board?

This should be fairly trivial, if I didn't have so many projects on my plate already I'd take a crack at it.

Correct, all my projects are custom ICs replacements for arcade boards  I think that for doing these things, first of all, you must be an enthusiast of this vintage hardware more than having a billion of electronis skills  And I feel you may be the right guy for a fruitful collaboration.Give me a shout if interested 

[james_s]

Well it does seem like something that could be interesting, I'm an amateur when it comes to HDL but I have managed to make several complete recreations of classic games in FPGAs. I use VHDL, never got the hang of Verilog. I'm a bit rusty at the moment having not messed with it in a while but I have been thinking I should jump back into it one of these days. Most of the stuff I've done I've released as open source.

www.github.com/james10952001

[caius]

Well it does seem like something that could be interesting, I'm an amateur when it comes to HDL but I have managed to make several complete recreations of classic games in FPGAs. I use VHDL, never got the hang of Verilog. I'm a bit rusty at the moment having not messed with it in a while but I have been thinking I should jump back into it one of these days. Most of the stuff I've done I've released as open source.

www.github.com/james10952001

Very good stuff
I guess you started from available schematics.Is the code tested on some DEV board?Anyway, feel free to join my project whenever you want, VHDL or Verilog doesn't matter 

[emece67]

.

[tggzzz]

Some years ago I was involved in a little project aimed to convert Quartus (or maybe MAX+plusII, cannot remember) schematics into VHDL. The project was promptly mutated into post-processing the Quartus generated (from schematics) structural VHDL into a more readable, user friendly and corporate style guide compliant, VHDL flavor.

You can convert a schematic netlist into VHDL. What did you do about the behaviour of the blocks connected together by the netlist?

Background: almost 40 years ago a salesman wanted my company to produce simulation models of 74 series logic. They didn't care about accuracy nor what aspects of the logic was/wasn't modelled. Since all they were after was to be able for a customer to tick a box in their list of requirements, I declined to quote.

[emece67]

.

[caius]

In our case all primitives were gates and flip-flops and some other simple primitives from Quartus/MAX+plusII libraries, so their behavior was clear and you can use the models provided by Quartus/MAX+plusII. But the behavioral models of 74 series chips seem simple enough to not to worry about them (somebody has even posted a link where many verilog models of 74 chips can be found). Only the PLD seem problematic.

Yes, my schematics seems quite straightforward.As for PLDs, I can always translate equations into HDL.But, as said, the main problem is re-drawing schematics into Quartus block diagram, its GUI is awful and cumbersone light years back to the Kicad one.I was just wondering if there are other good EDA able to translate their schematics in HDL.Perhaps Altium or Cadstar?

[AndyC_772]

I'd strongly advise against using schematic entry as a way to program an FPGA. It's all well and good as an educational tool (look! see! you can draw a schematic and the chip behaves just like the circuit you drew!), but you end up with a design which is very much tied to that particular synthesis tool and part vendor.

As I mentioned before, that might be OK given that this design is 'dead', but translating a known-good schematic that uses simple logic elements into HDL really isn't difficult and you end up with something much more manageable and portable.

You've done the hard part reverse-engineering the original custom ICs and proving that your derived schematic works. If I were you I'd take this opportunity to learn the basics of VHDL or Verilog, using one of your 74 series designs as a straightforward example.

[james_s]

Very good stuff
I guess you started from available schematics.Is the code tested on some DEV board?Anyway, feel free to join my project whenever you want, VHDL or Verilog doesn't matter 

Yes I started with schematics from the manuals I found for the games and yes all of the ones I've released are tested and ready to go on the EP2C5T144C8 mini boards you can get for about $12 from China.

Do you have a set of schematics somewhere? Is there specific hardware you are already targeting? I have Altera Quartus and Xilinx ISE environments set up and working and I have dev boards from both vendors. I could take a crack at one of these if you can test the results.

[caius]

Do you have a set of schematics somewhere? Is there specific hardware you are already targeting? I have Altera Quartus and Xilinx ISE environments set up and working and I have dev boards from both vendors. I could take a crack at one of these if you can test the results.

I can test everything (after done a proper PCB, obviously or using a DEV board which I could get) 
All my TTL replacements  have been successfully tested on real hardware (the arcade PCBs), they works perfectly.Most of my devices are good so far, schematics were not so wide hence I'm happy to use SMD TTLs (SOIC or TSSOP) obtaining same dimensions of original IC.But some of them have big equivalent circuits, take for example the attached ones.It's unthinkable to make a TTL version (even with surface mounted gates) if not for prototyping and to validate the schematics.If you really want to try, I'm be happy to share my schematics with you but keep in mind the arcade PCBs are +5 V powered as well as for the busses, that's why I have used obsolete +5V CPLDs (like Altera MAX7000 or ATF15xx) for some on them (with code not written by me, I made the hardware part only).However, nothing prevents us to use modern 3.3V/1.25V CPLD or FPGA although this will add further complexity to the projects (voltage regulation, level shifting, etc) as well as price increasing.I'd want my devices as much simple (and cheap) as possible