Please restore the .qip files

[gyurco]

When using the module in external projects, it's not really convenient to use an external tool to convert the yaml to qip. And then why https://github.com/jotego/jtopl/blob/master/hdl/jtopl2.qip kept in the repo, but jt26.qip is not? Thanks for considering adding back the qips ;)

[jotego]

I'm really trying to get rid of all the .qip files. Some are still there because they've hidden from me!

The tool jtfiles.go is open source too and part of JTFRAME but I get your point. How about storing the .qip files in a separate folder (not in hdl) for the FM JT modules? Like in a target/quartus folder?

[gyurco]

That would be also great, if you put them into target/quartus, or syn, fpga, whatever folder...

If I have to use jtfiles.go, then:

• I must add it to my repos.
• I have to find a way to run it as a pre-flow script (where I think only TCL is allowed). And I had some headaches running it when it cannot find gopkg.in/yaml.v2.

[jotego]

Adding the package gopkg.in/yaml.v2 can be a headache indeed. Other than that, I am quite happy about jtfiles. I only need a single file to set the dependencies and the required files for simulation or synthesis are generated from it. At some point, I suppose I'll target non-Quartus FPGA devices too for which QIP is not used but with JTFILES I'll cover that easily.

Anyway, I'll be adding them back or if there's any you need urgently, you can just add them to target/quartus and make a PR.

[gyurco]

BTW, did you consider moving back to python? :)

import yaml

usually works well, and recent 3.x versions should be consistent now.

[jotego]

I worked with Python a few years ago in a large project and eventually it became unmanageable. Modern C++ has become an ugly mess where they take features of any other language. Plain C has a standard library that covers too little of modern programming. Javascript it's too relaxed and high level. Go works well for me because it's like C for the 21st century. Eventually I'll replace all the files with Go equivalents.

[gyurco]

I wouldn't object against Go if a simple import from a shared location could work as I expect, but maybe that will improve (or I have to improve myself...)

[jotego]

I should add some link to JTFRAME documentation about the Go import...

[gyurco]

Maybe just mention

go get gopkg.in/yaml.v2

However in the past, it didn't work for me, only if I moved some files manually around. Now it works. Strange.

[gyurco]

I found an issue now using jtfiles.go to convert .yamls to .qips

go run /usr/local/bin/jtfiles.go  -parse jt2413.yaml                                                                                                                  [|]

Creates something like:

set_global_assignment -name VERILOG_FILE jtopl.v

However for universal use, it has to be:

set_global_assignment -name VERILOG_FILE [file join $::quartus(qip_path) ../../hdl/jtopl.v]

(BTW, is it possible to set a go file as executable, and run just as a normal command? Shebang on the first line, e.g. #!/bin/go run doesn't work)

[jotego]

Not sure about the Shebang but you can always compile the go file and copy it to /usr/bin for instance.

However, currently it's really thought to be used inside a JT repository where some variable are defined. I need to check whether it covers a stand-alone use for the individual FM modules.

Missing the qip_path is not a problem if you get the file location relative to the MiST project folder, which is the expected use case for qip. Like for simulation files, it generates the path relative to the current folder because the simulator will be sitting there.

[gyurco]

But if the location depends on the folder of the project file, then it cannot be used universally (e.g. this one cannot go into your repo to target/quartus), it's only for private use then.

[jotego]

Yes, for your use case it makes sense to use the qip_path. For the temporary qip files generated in a JT core structure, it is not needed. Those files are not even part of git.