github-actions[bot] on nightly
synth/elab-vhdl_values: use a p… vhdl-canon: remove unused canon… synth-vhdl_expr: avoid a memocy… and 6 more (compare)
tgingold on master
synth/elab-vhdl_values: use a p… vhdl-canon: remove unused canon… synth-vhdl_expr: avoid a memocy… and 6 more (compare)
github-actions[bot] on nightly
elab-vhdl_context: remove cur_s… synth-vhdl_stmts: add comments … synth-vhdl_stmts: avoid a crash… and 1 more (compare)
tgingold on master
elab-vhdl_context: remove cur_s… synth-vhdl_stmts: add comments … synth-vhdl_stmts: avoid a crash… and 1 more (compare)
Well, sure, but since I'm working primarily with GHDL (using VSCode) then porting it to ISE when it will be done, I would rather stay as strict as possible.
That's understandable! It seems all the EDA tools have different default settings for the LRM compliance depending on what users complain about, so it can be a very thin line. The best way is to be strict and comply yourself as this will be a tooling bug if they don't comply with that style. It's tough with the older standards, though, and I totally get it
On fresh master, synthesis report few design-related errors then crash btw
Yes, synthesis is an experimental feature yet. In fact, it is very active and multiple related issues are being fixed every day.
julien@R220:~/Projets/VHDL/MPU_KAT$ ghdl --synth --std=08 --workdir=work mpu
rtl/mpu.vhdl:200:5:error: latch infered for net "query_bus"
rtl/mpu.vhdl:15:9:error: multiple assignments for offsets 0:23
rtl/mpu.vhdl:108:12:error: multiple assignments for offsets 0:15
rtl/mpu.vhdl:95:12:warning: signal "out_cmd" is never assigned and has no default value
rtl/mpu.vhdl:96:12:warning: signal "out_data" is never assigned and has no default value
(then a GHDL bug occured message which I may post if it's of any actual use on the current developement stage)
Yes, please.
On an issue or directly here ? (I mean, I don't have much to say beside "I tried and it crashed" and I don't really have a mwe)
If you don't have a MWE, but you have some repo on GitHub, that's useful too. Many of the projects in #974 have been tested directly.
I believe that bidirectional ports are supported for I/O (top-level ports). But you cannot use bidirectional signals in modern FPGAs.
You can use bi-directional ports, at least all the modern FPGAs (KU+, Stratix, etc) I've used. But, there is a caveat. Not only does it turn into a mux, but you have to be extremely careful about multi-driven ports. If you aren't you get errors during implementation that lead you a stray