<rqou>
hey lazyweb, can someone test if <your favorite proprietary vhdl tool> accepts this? entity test is type test is (foo); alias test2 is test; begin end;
<rqou>
(ghdl says no, spec is imho unclear)
azonenberg_work has quit [Ping timeout: 240 seconds]
pie_ has joined ##openfpga
Bike has quit [Quit: leaving]
m_t has quit [Quit: Leaving]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 245 seconds]
scrts has joined ##openfpga
<rqou>
not sure if i'm reading the spec poorly or what, but VHDL aliases seem to be a pretty broken feature overall
<openfpga-github>
[openfpga] azonenberg pushed 1 new commit to master: https://git.io/v9aUG
<openfpga-github>
openfpga/master 163b1f5 Andrew Zonenberg: Added legacy-crowbar-import dir with copy of old libcrowbar code from Antikernel repo. Needs to get totally rewritten, just shoving it here for easy reference
<azonenberg_work>
This is the first i've seen specifically for a greenpak
<whitequark>
azonenberg_work: oh dang
<whitequark>
they turned off autoindex
<whitequark>
I was going to rerun my lftp job
<azonenberg_work>
rqou: re 163b1f5
<Zarutian>
azonenberg: "for internal use only" is just a standar CYA nowdays.
<azonenberg_work>
Zarutian: no its not
<azonenberg_work>
this doc has details on bits they dont doc in other datasheets
<azonenberg_work>
Bits that, in fact, were *removed* from published datasheets of other chips in later revisions
<Zarutian>
azonenberg_work: ya misunderstood me. It is an internal CYA
<azonenberg_work>
Oh
<azonenberg_work>
yeah maybe
<azonenberg_work>
but all of the reserved/confidential stuff was highlighted bright red
<azonenberg_work>
like "remove this in the public datasheet rev" lol
<Zarutian>
many times designers of these chips do not care
<azonenberg_work>
in any case
<azonenberg_work>
good info to have :p
<azonenberg_work>
rqou: i just pushed all of my old coolrunner-2 code to the openfpga repo from antikernel as it really belongs here
<azonenberg_work>
Don't actually try using any of it
<azonenberg_work>
most of it has to be redone from scratch
<azonenberg_work>
But it's there for reference
<azonenberg_work>
i have a lot of hard coded magic that has to be replaced with proper derivations so i can support larger devices, etc
<azonenberg_work>
and the general code structure is awful :P
<azonenberg_work>
and the PAR i'm using is a greedy algorithm that doesnt exactly work
<azonenberg_work>
but as an executable form of bitstream documentation its not toooooo bad
pie_ has joined ##openfpga
azonenberg_work has quit [Ping timeout: 264 seconds]
pie_ has quit [Ping timeout: 240 seconds]
digshadow has quit [Quit: Leaving.]
amclain has joined ##openfpga
azonenberg_work has joined ##openfpga
Bike has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
cr1901_modern has joined ##openfpga
pie_ has joined ##openfpga
cr1901_modern1 has quit [Ping timeout: 240 seconds]
digshadow has joined ##openfpga
scrts has quit [Ping timeout: 246 seconds]
<rqou>
hmm after reading a whole bunch of stuff, i'm now pretty convinced that "alias test is test;" is legal VHDL (and GHDL is wrong)
<rqou>
this becomes really hilarious when your alias creates a "new view" of an existing object (such as aliasing test to test(0) )
m_t has joined ##openfpga
<rqou>
oh wtf
<rqou>
ghdl has different behavior when given --std=08
<rqou>
it's actually correct in that case
digshadow has quit [Quit: Leaving.]
<lain>
yes
<lain>
tristan seems pretty pedantic about ghdl being standards compliant
<lain>
even when other sims break spec for ease of use :P
<lain>
I can't argue with following the letter of the spec though; it pisses me off when I have a nice clean implementation of something and then I have to add quirks because nobody else read the spec heh.
<rqou>
hrm, actually no
<rqou>
it still rejects "alias test is test"
<rqou>
it accepts "alias test2 is test" where "test" is an enumeration literal in the same declarative region
<rqou>
that's the really dumb case
<rqou>
but i don't see how it's possible to accept "alias test2 is test" while rejecting "alias test is test" according to the rules of the spec?
<rqou>
aaaaah i see it
<rqou>
the very specific way the "scope of the declaration" interacts with "visibility" forbids "alias test is test"
<rqou>
ghdl returns the wrong error message
<lain>
one of these days I need to write a C# interface to ghdl's VPI/VHPI stuff
<lain>
and see if it is actually reliable
<lain>
vhdl is just not suitable for complex testbenches lol, it takes too much effort
<rqou>
i'm going to go file a bug to ask for a better error message in this particular hilarious case
<lain>
:D
<rqou>
actually, wait
<rqou>
it's still broken
<lain>
I can't handle this emotional rollercoaster, rqou
<rqou>
what is supposed to happen when i write the following?
<rqou>
package test is
<rqou>
type test is (foo);
<rqou>
alias test2 is test;
<rqou>
alias test is test2;
<rqou>
end;
<rqou>
i believe this is legal
<lain>
I'd have to look at the spec, and I'm too lazy :P
<rqou>
you have to read between the lines a huge amount
<lain>
I found some pretty serious ambiguities in the spec recently
<rqou>
you also need to read IR2099 to understand what is happening here
<lain>
also a major, stupid limitation: you can't make arrays of protected or access types
<rqou>
hmm, i'm curious what the ambiguity you found was?
pie_ has quit [Quit: Leaving]
<lain>
I didn't even know these IR things were a thing
<rqou>
me neither, i found them yesterday
<lain>
and hm, trying to remember what the ambiguity was
<lain>
oh
<lain>
so I've been condensing large port lists to records, one record for each direction, for example
<lain>
but I ran into a case where I had two different processes driving different signals, but both signals were in the same record
<lain>
so for example I had something like type sigs_out is record gnt, valid : std_logic; end record;
<lain>
one process drove sigs_out.gnt, the other .valid
<lain>
the results differed by simulator
<lain>
and as best I can tell, the spec is ambiguous. though I was mad and just hacked around it rather than digging into the spec as deep as I should have :P
<rqou>
ah i haven't even gotten to those parts of the spec yet
<rqou>
still trying to fully wrap my head around scoping rules
<lain>
specifically the issue seems to be that simulators will assign default values to undriven signals in records /per process/
<lain>
and the resulting signals were 'X' because they were driven default ('U' iirc) by one process and '1'/'0' by the other
<lain>
I have no idea how a synthesis tool would handle this
<lain>
but I find that to me a major oversight
<rqou>
you can try writing a custom resolution function for the record, just to expose more bugs :P :P
<rqou>
i wonder if resolution functions even actually work?
<lain>
if you then do this, it works: signal gnt, valid : std_logic; ... then in the architecture body, sigs_in.gnt <= gnt; sigs_in.valid <= valid;
<lain>
then drive gnt and valid local signals from different processes, no problem
<lain>
it's architecturally equivalent
<lain>
but somehow it works
<lain>
this bothers me deeply :P
<rqou>
i asked my father about this and he said that he tried to use resolution functions over a decade ago in one of the earliest generation vhdl simulators and it basically just didn't work
<lain>
haha
<lain>
well, std_logic is the resolved version of std_ulogic, and that seems to ... resolve. so maybe?
<rqou>
and he specifically wanted this feature because he was trying to model a multi-master bus
<rqou>
he said that eventually he just wrote a "do_bus" function that manually had its inputs given
<lain>
holy crap @ that unfeature
<rqou>
wait
<rqou>
i found an even more fun issue i think
<lain>
ohno
<rqou>
there's a non-normative note that states "The rules defining immediate scope, hiding, and visibility imply that a reference to an identifier, character literal, or operator symbol within its own declaration is illegal (except for design units)."
<rqou>
but afaik that's just not true for aliases
<rqou>
it gives as an example that this should be illegal: constant K: INTEGER := K*K;
<rqou>
because if there were another K in the same declarative region, this declaration creates a homograph
<rqou>
if there is no visible K, then that's obviously an error
<rqou>
so the assumption is that K must have come from an outer declarative region
<rqou>
and the key point is that this inner constant K hides the outer K
<rqou>
it starts hiding at the beginning of the declaration but doesn't become visible (and usable) until the end
<rqou>
hence there is no way this statement can be valid
<rqou>
but hiding is defined in terms of homographs